<?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>150</NO>
    <DATE>Monday, August 5, 2024</DATE>
    <UNITNAME>Contents</UNITNAME>
    <CNTNTS>
        <AGCY>
            <EAR>
                Agriculture
                <PRTPAGE P="iii"/>
            </EAR>
            <HD>Agriculture Department</HD>
            <CAT>
                <HD>NOTICES</HD>
                <DOCENT>
                    <DOC>Agency Information Collection Activities; Proposals, Submissions, and Approvals, </DOC>
                    <PGS>63398</PGS>
                    <FRDOCBP>2024-17140</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>63416-63417</PGS>
                    <FRDOCBP>2024-17175</FRDOCBP>
                </DOCENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Army</EAR>
            <HD>Army Department</HD>
            <CAT>
                <HD>NOTICES</HD>
                <DOCENT>
                    <DOC>Agency Information Collection Activities; Proposals, Submissions, and Approvals, </DOC>
                    <PGS>63417-63420</PGS>
                    <FRDOCBP>2024-17163</FRDOCBP>
                      
                    <FRDOCBP>2024-17164</FRDOCBP>
                      
                    <FRDOCBP>2024-17168</FRDOCBP>
                      
                    <FRDOCBP>2024-17170</FRDOCBP>
                      
                    <FRDOCBP>2024-17176</FRDOCBP>
                </DOCENT>
                <SJ>Hearings, Meetings, Proceedings, etc.:</SJ>
                <SJDENT>
                    <SJDOC>Advisory Committee on Arlington National Cemetery, </SJDOC>
                    <PGS>63418-63419</PGS>
                    <FRDOCBP>2024-17224</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Centers Disease</EAR>
            <HD>Centers for Disease Control and Prevention</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Hearings, Meetings, Proceedings, etc.:</SJ>
                <SJDENT>
                    <SJDOC>Advisory Committee on Breast Cancer in Young Women, </SJDOC>
                    <PGS>63433</PGS>
                    <FRDOCBP>2024-17219</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Healthcare Infection Control Practices Advisory Committee, </SJDOC>
                    <PGS>63432-63433</PGS>
                    <FRDOCBP>2024-17220</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Children</EAR>
            <HD>Children and Families Administration</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Agency Information Collection Activities; Proposals, Submissions, and Approvals:</SJ>
                <SJDENT>
                    <SJDOC>State Supplemental Nutrition Assistance Program Agency National Directory of New Hires Matching Program Performance Report, </SJDOC>
                    <PGS>63434</PGS>
                    <FRDOCBP>2024-17148</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Coast Guard</EAR>
            <HD>Coast Guard</HD>
            <CAT>
                <HD>RULES</HD>
                <SJ>Safety Zone:</SJ>
                <SJDENT>
                    <SJDOC>Port Huron Float Down, St. Clair River, Port Huron, MI, </SJDOC>
                    <PGS>63288-63290</PGS>
                    <FRDOCBP>2024-17160</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Recurring Safety Zones in Captain of the Port Northern Great Lakes Zone, </SJDOC>
                    <PGS>63290</PGS>
                    <FRDOCBP>2024-17158</FRDOCBP>
                </SJDENT>
                <SJ>Security Zone:</SJ>
                <SJDENT>
                    <SJDOC>Santa Monica Bay, Pacific Palisades, CA, </SJDOC>
                    <PGS>63286-63288</PGS>
                    <FRDOCBP>2024-17145</FRDOCBP>
                </SJDENT>
                <SJ>Special Local Regulation:</SJ>
                <SJDENT>
                    <SJDOC>Cayuga Lake, Ithaca, NY, </SJDOC>
                    <PGS>63284-63286</PGS>
                    <FRDOCBP>2024-17121</FRDOCBP>
                </SJDENT>
                <SJ>Special Local Regulations:</SJ>
                <SJDENT>
                    <SJDOC>Recurring Marine Events, Sector Key West, Update; Correction, </SJDOC>
                    <PGS>63290-63291</PGS>
                    <FRDOCBP>2024-17183</FRDOCBP>
                </SJDENT>
            </CAT>
            <CAT>
                <HD>PROPOSED RULES</HD>
                <SJ>Great Lakes Pilotage Rates:</SJ>
                <SJDENT>
                    <SJDOC>2025 Annual Review, </SJDOC>
                    <PGS>63334-63381</PGS>
                    <FRDOCBP>2024-17028</FRDOCBP>
                </SJDENT>
                <SJ>Safety Zone:</SJ>
                <SJDENT>
                    <SJDOC>Upper Galveston Bay, Kemah, TX, </SJDOC>
                    <PGS>63331-63334</PGS>
                    <FRDOCBP>2024-17144</FRDOCBP>
                </SJDENT>
            </CAT>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Request for Membership Application:</SJ>
                <SJDENT>
                    <SJDOC>National Merchant Mariner Medical Advisory Committee, </SJDOC>
                    <PGS>63439-63440</PGS>
                    <FRDOCBP>2024-17159</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Commerce</EAR>
            <HD>Commerce Department</HD>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>Economic Analysis Bureau</P>
            </SEE>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>Economic Development Administration</P>
            </SEE>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>International Trade Administration</P>
            </SEE>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>National Institute of Standards and Technology</P>
            </SEE>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>National Oceanic and Atmospheric Administration</P>
            </SEE>
        </AGCY>
        <AGCY>
            <EAR>Committee Implementation</EAR>
            <HD>Committee for the Implementation of Textile Agreements</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Determination:</SJ>
                <SJDENT>
                    <SJDOC>Textile and Apparel Commercial Availability Provision of the Dominican Republic-Central America-United States Free Trade Agreement, </SJDOC>
                    <PGS>63415-63416</PGS>
                    <FRDOCBP>2024-17233</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Comptroller</EAR>
            <HD>Comptroller of the Currency</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Agency Information Collection Activities; Proposals, Submissions, and Approvals:</SJ>
                <SJDENT>
                    <SJDOC>Bank Appeals Follow-Up Questionnaire, </SJDOC>
                    <PGS>63491-63492</PGS>
                    <FRDOCBP>2024-17244</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Customer Complaint Form, </SJDOC>
                    <PGS>63490-63491</PGS>
                    <FRDOCBP>2024-17242</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Registration of Mortgage Loan Originators, </SJDOC>
                    <PGS>63492-63494</PGS>
                    <FRDOCBP>2024-17147</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Consumer Product</EAR>
            <HD>Consumer Product Safety Commission</HD>
            <CAT>
                <HD>NOTICES</HD>
                <DOCENT>
                    <DOC>Meetings; Sunshine Act, </DOC>
                    <PGS>63416</PGS>
                    <FRDOCBP>2024-17297</FRDOCBP>
                </DOCENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Defense Department</EAR>
            <HD>Defense Department</HD>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>Air Force Department</P>
            </SEE>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>Army Department</P>
            </SEE>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>Navy Department</P>
            </SEE>
            <CAT>
                <HD>NOTICES</HD>
                <DOCENT>
                    <DOC>Agency Information Collection Activities; Proposals, Submissions, and Approvals, </DOC>
                    <PGS>63421-63423</PGS>
                    <FRDOCBP>2024-17177</FRDOCBP>
                      
                    <FRDOCBP>2024-17210</FRDOCBP>
                      
                    <FRDOCBP>2024-17211</FRDOCBP>
                </DOCENT>
                <SJ>Charter Amendments, Establishments, Renewals and Terminations:</SJ>
                <SJDENT>
                    <SJDOC>Army Education Advisory Committee, </SJDOC>
                    <PGS>63423</PGS>
                    <FRDOCBP>2024-17228</FRDOCBP>
                </SJDENT>
                <SJ>Hearings, Meetings, Proceedings, etc.:</SJ>
                <SJDENT>
                    <SJDOC>Defense Advisory Committee on Women in the Services, </SJDOC>
                    <PGS>63420-63421</PGS>
                    <FRDOCBP>2024-17247</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Economic Analysis Bureau</EAR>
            <HD>Economic Analysis Bureau</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Agency Information Collection Activities; Proposals, Submissions, and Approvals:</SJ>
                <SJDENT>
                    <SJDOC>Services Surveys: Quarterly Survey of Financial Services Transactions between U.S. Financial Services Providers and Foreign Persons, </SJDOC>
                    <PGS>63398-63400</PGS>
                    <FRDOCBP>2024-17180</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Economic Development</EAR>
            <HD>Economic Development Administration</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Hearings, Meetings, Proceedings, etc.:</SJ>
                <SJDENT>
                    <SJDOC>National Advisory Council on Innovation and Entrepreneurship; Correction, </SJDOC>
                    <PGS>63400</PGS>
                    <FRDOCBP>2024-17198</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>NOTICES</HD>
                <DOCENT>
                    <DOC>Agency Information Collection Activities; Proposals, Submissions, and Approvals, </DOC>
                    <PGS>63426-63428</PGS>
                    <FRDOCBP>2024-17216</FRDOCBP>
                      
                    <FRDOCBP>2024-17217</FRDOCBP>
                </DOCENT>
                <SJ>Hearings, Meetings, Proceedings, etc.:</SJ>
                <SJDENT>
                    <SJDOC>Industrial Technology Innovation Advisory Committee, </SJDOC>
                    <PGS>63428</PGS>
                    <FRDOCBP>2024-17241</FRDOCBP>
                </SJDENT>
                <SJ>Record of Decision:</SJ>
                <SJDENT>
                    <SJDOC>Issuance of a Loan Guarantee to Holtec Palisades, LLC for General Restoration and Maintenance Activities of the Palisades Nuclear Plant, </SJDOC>
                    <PGS>63424-63426</PGS>
                    <FRDOCBP>2024-17218</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>
                Environmental Protection
                <PRTPAGE P="iv"/>
            </EAR>
            <HD>Environmental Protection Agency</HD>
            <CAT>
                <HD>RULES</HD>
                <SJ>Pesticide Tolerance; Exemptions, Petitions, Revocations, etc.:</SJ>
                <SJDENT>
                    <SJDOC>Potassium Carbonate, </SJDOC>
                    <PGS>63291-63296</PGS>
                    <FRDOCBP>2024-17003</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Export Import</EAR>
            <HD>Export-Import Bank</HD>
            <CAT>
                <HD>NOTICES</HD>
                <DOCENT>
                    <DOC>Applications for Long-Term Loans or Financial Guarantees in Excess of $100 million, </DOC>
                    <PGS>63431</PGS>
                    <FRDOCBP>2024-17137</FRDOCBP>
                </DOCENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Federal Aviation</EAR>
            <HD>Federal Aviation Administration</HD>
            <CAT>
                <HD>RULES</HD>
                <DOCENT>
                    <DOC>Standard Instrument Approach Procedures, and Takeoff Minimums and Obstacle Departure Procedures; Miscellaneous Amendments, </DOC>
                    <PGS>63281-63284</PGS>
                    <FRDOCBP>2024-17117</FRDOCBP>
                      
                    <FRDOCBP>2024-17118</FRDOCBP>
                </DOCENT>
            </CAT>
            <CAT>
                <HD>PROPOSED RULES</HD>
                <SJ>Airspace Designations and Reporting Points:</SJ>
                <SJDENT>
                    <SJDOC>Gainesville, FL, </SJDOC>
                    <PGS>63329-63330</PGS>
                    <FRDOCBP>2024-17179</FRDOCBP>
                </SJDENT>
            </CAT>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Agency Information Collection Activities; Proposals, Submissions, and Approvals:</SJ>
                <SJDENT>
                    <SJDOC>Airport Noise Compatibility Planning, </SJDOC>
                    <PGS>63466-63467</PGS>
                    <FRDOCBP>2024-17134</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Federal Communications</EAR>
            <HD>Federal Communications Commission</HD>
            <CAT>
                <HD>RULES</HD>
                <SJ>Allocation of Spectrum:</SJ>
                <SJDENT>
                    <SJDOC>Non-Federal Space Launch Operations; Federal Earth Stations Communicating with Non-Federal Fixed Satellite Service Space Stations; and Federal Space Station Use of the 399.9-400.05 MHz Band, </SJDOC>
                    <PGS>63296-63325</PGS>
                    <FRDOCBP>2024-16638</FRDOCBP>
                </SJDENT>
            </CAT>
            <CAT>
                <HD>PROPOSED RULES</HD>
                <DOCENT>
                    <DOC>Disclosure and Transparency of Artificial Intelligence-Generated Content in Political Advertisements, </DOC>
                    <PGS>63381-63393</PGS>
                    <FRDOCBP>2024-16977</FRDOCBP>
                </DOCENT>
            </CAT>
            <CAT>
                <HD>NOTICES</HD>
                <DOCENT>
                    <DOC>Agency Information Collection Activities; Proposals, Submissions, and Approvals, </DOC>
                    <PGS>63431-63432</PGS>
                    <FRDOCBP>2024-17203</FRDOCBP>
                </DOCENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Federal Election</EAR>
            <HD>Federal Election Commission</HD>
            <CAT>
                <HD>NOTICES</HD>
                <DOCENT>
                    <DOC>Meetings; Sunshine Act, </DOC>
                    <PGS>63432</PGS>
                    <FRDOCBP>2024-17299</FRDOCBP>
                </DOCENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Federal Energy</EAR>
            <HD>Federal Energy Regulatory Commission</HD>
            <CAT>
                <HD>NOTICES</HD>
                <DOCENT>
                    <DOC>Combined Filings, </DOC>
                    <PGS>63428-63429, 63431</PGS>
                    <FRDOCBP>2024-17196</FRDOCBP>
                      
                    <FRDOCBP>2024-17197</FRDOCBP>
                </DOCENT>
                <SJ>Environmental Assessments; Availability, etc.:</SJ>
                <SJDENT>
                    <SJDOC>Sho-Me Power Electric Cooperative, </SJDOC>
                    <PGS>63430-63431</PGS>
                    <FRDOCBP>2024-17199</FRDOCBP>
                </SJDENT>
                <DOCENT>
                    <DOC>Records Governing Off-the-Record Communications, </DOC>
                    <PGS>63429-63430</PGS>
                    <FRDOCBP>2024-17195</FRDOCBP>
                </DOCENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Federal Railroad</EAR>
            <HD>Federal Railroad Administration</HD>
            <CAT>
                <HD>NOTICES</HD>
                <DOCENT>
                    <DOC>Agency Information Collection Activities; Proposals, Submissions, and Approvals, </DOC>
                    <PGS>63468-63471</PGS>
                    <FRDOCBP>2024-17186</FRDOCBP>
                      
                    <FRDOCBP>2024-17189</FRDOCBP>
                </DOCENT>
                <SJ>Request for Amendment:</SJ>
                <SJDENT>
                    <SJDOC>Brightline Trains Florida, Positive Train Control Safety Plan and Positive Train Control System, </SJDOC>
                    <PGS>63467</PGS>
                    <FRDOCBP>2024-17135</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Florida East Coast Railway, Positive Train Control Safety Plan and Positive Train Control System, </SJDOC>
                    <PGS>63471</PGS>
                    <FRDOCBP>2024-17136</FRDOCBP>
                </SJDENT>
                <SJ>Request for Information:</SJ>
                <SJDENT>
                    <SJDOC>Collaboration and Data Sharing for Railroad Operations Analysis, </SJDOC>
                    <PGS>63471-63473</PGS>
                    <FRDOCBP>2024-17185</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Fish</EAR>
            <HD>Fish and Wildlife Service</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Agency Information Collection Activities; Proposals, Submissions, and Approvals:</SJ>
                <SJDENT>
                    <SJDOC>National Double-Crested Cormorant Survey, </SJDOC>
                    <PGS>63442-63444</PGS>
                    <FRDOCBP>2024-17234</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Food and Drug</EAR>
            <HD>Food and Drug Administration</HD>
            <CAT>
                <HD>PROPOSED RULES</HD>
                <SJ>Color Additive Petition:</SJ>
                <SJDENT>
                    <SJDOC>GNT USA, LLC, </SJDOC>
                    <PGS>63330-63331</PGS>
                    <FRDOCBP>2024-17090</FRDOCBP>
                </SJDENT>
            </CAT>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Charter Amendments, Establishments, Renewals and Terminations:</SJ>
                <SJDENT>
                    <SJDOC>Anesthetic and Analgesic Drug Products Advisory Committee, </SJDOC>
                    <PGS>63434-63435</PGS>
                    <FRDOCBP>2024-17248</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Drug Safety and Risk Management Advisory Committee, </SJDOC>
                    <PGS>63435-63436</PGS>
                    <FRDOCBP>2024-17243</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>General Services</EAR>
            <HD>General Services Administration</HD>
            <CAT>
                <HD>RULES</HD>
                <SJ>Acquisition Regulation:</SJ>
                <SJDENT>
                    <SJDOC>Federal Supply Schedule Economic Price Adjustment, </SJDOC>
                    <PGS>63325-63328</PGS>
                    <FRDOCBP>2024-16980</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>Children and Families Administration</P>
            </SEE>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>Food and Drug Administration</P>
            </SEE>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>National Institutes of Health</P>
            </SEE>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>Substance Abuse and Mental Health Services Administration</P>
            </SEE>
            <CAT>
                <HD>PROPOSED RULES</HD>
                <SJ>Health Data, Technology, and Interoperability:</SJ>
                <SJDENT>
                    <SJDOC>Patient Engagement, Information Sharing, and Public Health Interoperability, </SJDOC>
                    <PGS>63498-63811</PGS>
                    <FRDOCBP>2024-14975</FRDOCBP>
                </SJDENT>
            </CAT>
            <CAT>
                <HD>NOTICES</HD>
                <DOCENT>
                    <DOC>Interest Rate on Overdue Debts, </DOC>
                    <PGS>63436</PGS>
                    <FRDOCBP>2024-17139</FRDOCBP>
                </DOCENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Homeland</EAR>
            <HD>Homeland Security Department</HD>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>Coast Guard</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>63440-63442</PGS>
                    <FRDOCBP>2024-17181</FRDOCBP>
                </DOCENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Interior</EAR>
            <HD>Interior Department</HD>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>Fish and Wildlife Service</P>
            </SEE>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>Land Management Bureau</P>
            </SEE>
        </AGCY>
        <AGCY>
            <EAR>International Trade Adm</EAR>
            <HD>International Trade Administration</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Antidumping or Countervailing Duty Investigations, Orders, or Reviews:</SJ>
                <SJDENT>
                    <SJDOC>Brass Rod from Israel, </SJDOC>
                    <PGS>63410-63412</PGS>
                    <FRDOCBP>2024-17174</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Certain Quartz Surface Products from the People's Republic of China, </SJDOC>
                    <PGS>63400-63402</PGS>
                    <FRDOCBP>2024-17171</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Certain Uncoated Paper from Portugal, </SJDOC>
                    <PGS>63408-63410</PGS>
                    <FRDOCBP>2024-17250</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Citric Acid and Certain Citrate Salts from Belgium, Colombia, and Thailand, </SJDOC>
                    <PGS>63406</PGS>
                    <FRDOCBP>2024-17172</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Wooden Cabinets and Vanities and Components Thereof from the People's Republic of China; Correction, </SJDOC>
                    <PGS>63404-63405</PGS>
                    <FRDOCBP>2024-17165</FRDOCBP>
                </SJDENT>
                <SJ>Hearings, Meetings, Proceedings, etc.:</SJ>
                <SJDENT>
                    <SJDOC>Advisory Committee on Supply Chain Competitiveness, </SJDOC>
                    <PGS>63407</PGS>
                    <FRDOCBP>2024-17245</FRDOCBP>
                </SJDENT>
                <SJ>Sales at Less Than Fair Value; Determinations, Investigations, etc.:</SJ>
                <SJDENT>
                    <SJDOC>Brass Rod from Israel, </SJDOC>
                    <PGS>63402-63404</PGS>
                    <FRDOCBP>2024-17173</FRDOCBP>
                </SJDENT>
                <DOCENT>
                    <PRTPAGE P="v"/>
                    <DOC>Scope Rulings, </DOC>
                    <PGS>63407-63408</PGS>
                    <FRDOCBP>2024-17167</FRDOCBP>
                </DOCENT>
                <SJ>Updated Annual Listing of Foreign Government Subsidies:</SJ>
                <SJDENT>
                    <SJDOC>Articles of Cheese Subject to an In-Quota Rate of Duty, </SJDOC>
                    <PGS>63405-63406</PGS>
                    <FRDOCBP>2024-17166</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>International Trade Com</EAR>
            <HD>International Trade Commission</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Investigations; Determinations, Modifications, and Rulings, etc.:</SJ>
                <SJDENT>
                    <SJDOC>Glass Wine Bottles from Chile, China, and Mexico, </SJDOC>
                    <PGS>63445</PGS>
                    <FRDOCBP>2024-17200</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Labor Department</EAR>
            <HD>Labor Department</HD>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>Veterans Employment and Training Service</P>
            </SEE>
        </AGCY>
        <AGCY>
            <EAR>Land</EAR>
            <HD>Land Management Bureau</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Public Land Order:</SJ>
                <SJDENT>
                    <SJDOC>No. 7945; Extension of Public Land Order No. 6560, as Extended by Public Land Order No. 7610; Withdrawal of Wisdom Administrative Site, Montana, </SJDOC>
                    <PGS>63444</PGS>
                    <FRDOCBP>2024-17357</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>National Highway</EAR>
            <HD>National Highway Traffic Safety Administration</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Supplemental Initial Decision:</SJ>
                <SJDENT>
                    <SJDOC>Certain Frontal Driver and Passenger Air Bag Inflators Manufactured by ARC Automotive Inc. and Delphi Automotive Systems LLC, and Vehicles in Which Those Inflators Were Installed, Contain a Safety Defect, </SJDOC>
                    <PGS>63473-63490</PGS>
                    <FRDOCBP>2024-17251</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>National Institute</EAR>
            <HD>National Institute of Standards and Technology</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Hearings, Meetings, Proceedings, etc.:</SJ>
                <SJDENT>
                    <SJDOC>National Advanced Spectrum and Communications Test Network: Citizens Broadband Radio Service Sharing Ecosystem Assessment Test Plan Community Outreach, </SJDOC>
                    <PGS>63412</PGS>
                    <FRDOCBP>2024-17207</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>National Institute</EAR>
            <HD>National Institutes of Health</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Agency Information Collection Activities; Proposals, Submissions, and Approvals:</SJ>
                <SJDENT>
                    <SJDOC>The Impact of Clinical Research Training and Medical Education at the Clinical Center on Physician Careers in Academia and Clinical Research, </SJDOC>
                    <PGS>63436-63437</PGS>
                    <FRDOCBP>2024-17191</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>National Oceanic</EAR>
            <HD>National Oceanic and Atmospheric Administration</HD>
            <CAT>
                <HD>PROPOSED RULES</HD>
                <SJ>Endangered and Threatened Species:</SJ>
                <SJDENT>
                    <SJDOC>Protective Regulations for the Oceanic Whitetip Shark (Carcharhinus longimanus); Public Hearings, </SJDOC>
                    <PGS>63393-63394</PGS>
                    <FRDOCBP>2024-17152</FRDOCBP>
                </SJDENT>
                <SJ>Fisheries of the Northeastern United States:</SJ>
                <SJDENT>
                    <SJDOC>Framework Adjustment 16 to the Mackerel, Squid, and Butterfish Fishery Management Plan, </SJDOC>
                    <PGS>63394-63397</PGS>
                    <FRDOCBP>2024-17037</FRDOCBP>
                </SJDENT>
            </CAT>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Hearings, Meetings, Proceedings, etc.:</SJ>
                <SJDENT>
                    <SJDOC>Mid-Atlantic Fishery Management Council, </SJDOC>
                    <PGS>63413</PGS>
                    <FRDOCBP>2024-17230</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>New England Fishery Management Council, </SJDOC>
                    <PGS>63414</PGS>
                    <FRDOCBP>2024-17231</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Ocean Research Advisory Panel, </SJDOC>
                    <PGS>63413-63414</PGS>
                    <FRDOCBP>2024-17226</FRDOCBP>
                </SJDENT>
                <SJ>Permits; Applications, Issuances, etc.:</SJ>
                <SJDENT>
                    <SJDOC>Endangered Species; File No. 27686, </SJDOC>
                    <PGS>63414-63415</PGS>
                    <FRDOCBP>2024-17252</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Endangered Species; File No. 28148, </SJDOC>
                    <PGS>63412-63413</PGS>
                    <FRDOCBP>2024-17225</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>National Science</EAR>
            <HD>National Science Foundation</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Permits; Applications, Issuances, etc.:</SJ>
                <SJDENT>
                    <SJDOC>Antarctic Conservation Act, </SJDOC>
                    <PGS>63446-63447</PGS>
                    <FRDOCBP>2024-17206</FRDOCBP>
                      
                    <FRDOCBP>2024-17212</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Navy</EAR>
            <HD>Navy Department</HD>
            <CAT>
                <HD>NOTICES</HD>
                <DOCENT>
                    <DOC>Agency Information Collection Activities; Proposals, Submissions, and Approvals, </DOC>
                    <PGS>63423-63424</PGS>
                    <FRDOCBP>2024-17178</FRDOCBP>
                </DOCENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Nuclear Regulatory</EAR>
            <HD>Nuclear Regulatory Commission</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Agency Information Collection Activities; Proposals, Submissions, and Approvals:</SJ>
                <SJDENT>
                    <SJDOC>Licensing Requirements for the Independent Storage of Spent Nuclear Fuel and High-Level Radioactive Waste and Reactor-Related greater than Class C Waste, </SJDOC>
                    <PGS>63449-63450</PGS>
                    <FRDOCBP>2024-17190</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Planned Power Uprate-Related Licensing Submittals for All Power Reactor Licensees, </SJDOC>
                    <PGS>63448-63449</PGS>
                    <FRDOCBP>2024-17149</FRDOCBP>
                </SJDENT>
                <SJ>Environmental Impact Statements; Availability, etc.:</SJ>
                <SJDENT>
                    <SJDOC>Dresden Nuclear Power Station, Units 2 and 3, Constellation Energy Generation, LLC, </SJDOC>
                    <PGS>63450-63452</PGS>
                    <FRDOCBP>2024-17246</FRDOCBP>
                </SJDENT>
                <SJ>Guidance:</SJ>
                <SJDENT>
                    <SJDOC>Use of the Decommissioning Trust Fund During Operations for Major Radioactive Component Disposal, </SJDOC>
                    <PGS>63447-63448</PGS>
                    <FRDOCBP>2024-17236</FRDOCBP>
                </SJDENT>
                <DOCENT>
                    <DOC>Meetings; Sunshine Act, </DOC>
                    <PGS>63452</PGS>
                    <FRDOCBP>2024-17274</FRDOCBP>
                </DOCENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Personnel</EAR>
            <HD>Personnel Management Office</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Agency Information Collection Activities; Proposals, Submissions, and Approvals:</SJ>
                <SJDENT>
                    <SJDOC>Application for Senior Administrative Law Judge, Geographic Preference Statement for Senior Administrative Law Judge Applicant, </SJDOC>
                    <PGS>63453</PGS>
                    <FRDOCBP>2024-17238</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Postal Regulatory</EAR>
            <HD>Postal Regulatory Commission</HD>
            <CAT>
                <HD>NOTICES</HD>
                <DOCENT>
                    <DOC>New Postal Products, </DOC>
                    <PGS>63453-63454</PGS>
                    <FRDOCBP>2024-17208</FRDOCBP>
                </DOCENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Securities</EAR>
            <HD>Securities and Exchange Commission</HD>
            <CAT>
                <HD>NOTICES</HD>
                <DOCENT>
                    <DOC>Meetings; Sunshine Act, </DOC>
                    <PGS>63455-63456</PGS>
                    <FRDOCBP>2024-17348</FRDOCBP>
                </DOCENT>
                <SJ>Self-Regulatory Organizations; Proposed Rule Changes:</SJ>
                <SJDENT>
                    <SJDOC>ICE Clear Credit LLC, </SJDOC>
                    <PGS>63454-63455</PGS>
                    <FRDOCBP>2024-17146</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Small Business</EAR>
            <HD>Small Business Administration</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Disaster Declaration:</SJ>
                <SJDENT>
                    <SJDOC>Kansas; Public Assistance Only, </SJDOC>
                    <PGS>63456</PGS>
                    <FRDOCBP>2024-17194</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Minnesota, </SJDOC>
                    <PGS>63456</PGS>
                    <FRDOCBP>2024-17193</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>State Department</EAR>
            <HD>State Department</HD>
            <CAT>
                <HD>NOTICES</HD>
                <DOCENT>
                    <DOC>Proposed Establishment of a Federally Funded Research and Development Center, </DOC>
                    <PGS>63456-63458</PGS>
                    <FRDOCBP>2024-17213</FRDOCBP>
                </DOCENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Substance</EAR>
            <HD>Substance Abuse and Mental Health Services Administration</HD>
            <CAT>
                <HD>NOTICES</HD>
                <DOCENT>
                    <DOC>Agency Information Collection Activities; Proposals, Submissions, and Approvals, </DOC>
                    <PGS>63438-63439</PGS>
                    <FRDOCBP>2024-17142</FRDOCBP>
                </DOCENT>
                <DOCENT>
                    <DOC>Statement of Organization, Functions, and Delegations of Authority, </DOC>
                    <PGS>63437-63438</PGS>
                    <FRDOCBP>2024-17131</FRDOCBP>
                </DOCENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Surface Transportation</EAR>
            <HD>Surface Transportation Board</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Agency Information Collection Activities; Proposals, Submissions, and Approvals:</SJ>
                <SJDENT>
                    <SJDOC>Rail Carrier Financial Reports, </SJDOC>
                    <PGS>63459-63462</PGS>
                    <FRDOCBP>2024-17184</FRDOCBP>
                    <PRTPAGE P="vi"/>
                </SJDENT>
                <SJ>Exemption:</SJ>
                <SJDENT>
                    <SJDOC>Acquisition and Operation; Great Lakes Terminal Railroad, LLC, Great Lakes Terminal, LLC, CRRC Sifang America Inc., and Chicago Enterprise Owners' Association, </SJDOC>
                    <PGS>63458-63459</PGS>
                    <FRDOCBP>2024-17187</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Trade Representative</EAR>
            <HD>Trade Representative, Office of United States</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Hearings, Meetings, Proceedings, etc.:</SJ>
                <SJDENT>
                    <SJDOC>Action Following a Determination of Import Injury with Regard to Fine Denier Polyester Staple Fiber, </SJDOC>
                    <PGS>63465-63466</PGS>
                    <FRDOCBP>2024-17138</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>China's Compliance with World Trade Organization Commitments, </SJDOC>
                    <PGS>63462-63463</PGS>
                    <FRDOCBP>2024-17235</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Russia's Implementation of its World Trade Organization Commitments, </SJDOC>
                    <PGS>63463-63465</PGS>
                    <FRDOCBP>2024-17229</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Transportation Department</EAR>
            <HD>Transportation Department</HD>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>Federal Aviation Administration</P>
            </SEE>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>Federal Railroad Administration</P>
            </SEE>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>National Highway Traffic Safety Administration</P>
            </SEE>
        </AGCY>
        <AGCY>
            <EAR>Treasury</EAR>
            <HD>Treasury Department</HD>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>Comptroller of the Currency</P>
            </SEE>
        </AGCY>
        <AGCY>
            <EAR>Veteran Affairs</EAR>
            <HD>Veterans Affairs Department</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Agency Information Collection Activities; Proposals, Submissions, and Approvals:</SJ>
                <SJDENT>
                    <SJDOC>Paralympics and Olympics Monthly Training Allowance Application and Certification, </SJDOC>
                    <PGS>63494</PGS>
                    <FRDOCBP>2024-17215</FRDOCBP>
                </SJDENT>
                <SJ>Requests for Nominations:</SJ>
                <SJDENT>
                    <SJDOC>Geriatrics and Gerontology Advisory Committee, </SJDOC>
                    <PGS>63494-63495</PGS>
                    <FRDOCBP>2024-17214</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Veterans Employment</EAR>
            <HD>Veterans Employment and Training Service</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Requests for Nominations:</SJ>
                <SJDENT>
                    <SJDOC>Advisory Committee on Veterans' Employment, Training, and Employer Outreach, </SJDOC>
                    <PGS>63445-63446</PGS>
                    <FRDOCBP>2024-17221</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <PTS>
            <HD SOURCE="HED">Separate Parts In This Issue</HD>
            <HD>Part II</HD>
            <DOCENT>
                <DOC>Health and Human Services Department, </DOC>
                <PGS>63498-63811</PGS>
                <FRDOCBP>2024-14975</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>150</NO>
    <DATE>Monday, August 5, 2024</DATE>
    <UNITNAME>Rules and Regulations</UNITNAME>
    <RULES>
        <RULE>
            <PREAMB>
                <PRTPAGE P="63281"/>
                <AGENCY TYPE="F">DEPARTMENT OF TRANSPORTATION</AGENCY>
                <SUBAGY>Federal Aviation Administration</SUBAGY>
                <CFR>14 CFR Part 97</CFR>
                <DEPDOC>[Docket No. 31557; Amdt. No. 4123]</DEPDOC>
                <SUBJECT>Standard Instrument Approach Procedures, and Takeoff Minimums and Obstacle Departure Procedures; Miscellaneous Amendments</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Federal Aviation Administration (FAA), DOT.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Final rule.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>This rule establishes, amends, suspends, or removes Standard Instrument Approach Procedures (SIAPS) and associated Takeoff Minimums and Obstacle Departure procedures (ODPs) for operations at certain airports. These regulatory actions are needed because of the adoption of new or revised criteria, or because of changes occurring in the National Airspace System, such as the commissioning of new navigational facilities, adding new obstacles, or changing air traffic requirements. These changes are designed to provide safe and efficient use of the navigable airspace and to promote safe flight operations under instrument flight rules at the affected airports.</P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>This rule is effective August 5, 2024. The compliance date for each SIAP, associated Takeoff Minimums, and ODP is specified in the amendatory provisions.</P>
                    <P>The incorporation by reference of certain publications listed in the regulations is approved by the Director of the Federal Register as of August 5, 2024.</P>
                </EFFDATE>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>Availability of matters incorporated by reference in the amendment is as follows:</P>
                </ADD>
                <HD SOURCE="HD1">For Examination</HD>
                <P>1. U.S. Department of Transportation, Docket Ops-M30. 1200 New Jersey Avenue SE, West Bldg., Ground Floor, Washington, DC 20590-0001.</P>
                <P>2. The FAA Air Traffic Organization Service Area in which the affected airport is located;</P>
                <P>3. The office of Aeronautical Information Services, 6500 South MacArthur Blvd., Oklahoma City, OK 73169 or,</P>
                <P>
                    4. 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>
                <HD SOURCE="HD1">Availability</HD>
                <P>
                    All SIAPs and Takeoff Minimums and ODPs are available online free of charge. Visit the National Flight Data Center at 
                    <E T="03">nfdc.faa.gov</E>
                     to register. Additionally, individual SIAP and Takeoff Minimums and ODP copies may be obtained from the FAA Air Traffic Organization Service Area in which the affected airport is located.
                </P>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Thomas J. Nichols, Standards Section Manager, Flight Procedures and Airspace Group, Flight Technologies and Procedures Division, Office of Safety Standards, Flight Standards Service, Aviation Safety, Federal Aviation Administration. Mailing Address: FAA Mike Monroney Aeronautical Center, Flight Procedures and Airspace Group, 6500 South MacArthur Blvd., STB Annex, Bldg. 26, Room 217, Oklahoma City, OK 73099. Telephone (405) 954-1139.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>This rule amends 14 CFR part 97 by establishing, amending, suspending, or removes SIAPS, Takeoff Minimums and/or ODPS. The complete regulatory description of each SIAP and its associated Takeoff Minimums or ODP for an identified airport is listed on FAA form documents which are incorporated by reference in this amendment under 5 U.S.C. 552(a), 1 CFR part 51, and 14 CFR 97.20. The applicable FAA Forms are 8260-3, 8260-4, 8260-5, 8260-15A, 8260-15B, when required by an entry on 8260-15A, and 8260-15C.</P>
                <P>
                    The large number of SIAPs, Takeoff Minimums and ODPs, their complex nature, and the need for a special format make publication in the 
                    <E T="04">Federal Register</E>
                     expensive and impractical. Further, pilots do not use the regulatory text of the SIAPs, Takeoff Minimums or ODPs, but instead refer to their graphic depiction on charts printed by publishers or aeronautical materials. Thus, the advantages of incorporation by reference are realized and publication of the complete description of each SIAP, Takeoff Minimums and ODP listed on FAA form documents is unnecessary. This amendment provides the affected CFR sections and specifies the types of SIAPS, Takeoff Minimums and ODPs with their applicable effective dates. This amendment also identifies the airport and its location, the procedure, and the amendment number.
                </P>
                <HD SOURCE="HD1">Availability and Summary of Material Incorporated by Reference</HD>
                <P>
                    The material incorporated by reference is publicly available as listed in the 
                    <E T="02">ADDRESSES</E>
                     section.
                </P>
                <P>The material incorporated by reference describes SIAPS, Takeoff Minimums and/or ODPs as identified in the amendatory language for part 97 of this final rule.</P>
                <HD SOURCE="HD1">The Rule</HD>
                <P>This amendment to 14 CFR part 97 is effective upon publication of each separate SIAP, Takeoff Minimums and ODP as amended in the transmittal. Some SIAP and Takeoff Minimums and textual ODP amendments may have been issued previously by the FAA in a Flight Data Center (FDC) Notice to Air Missions (NOTAM) as an emergency action of immediate flights safety relating directly to published aeronautical charts.</P>
                <P>The circumstances that created the need for some SIAP and Takeoff Minimums and ODP amendments may require making them effective in less than 30 days. For the remaining SIAPs and Takeoff Minimums and ODPs, an effective date at least 30 days after publication is provided.</P>
                <P>
                    Further, the SIAPs and Takeoff Minimums and ODPs contained in this amendment are based on the criteria contained in the U.S. Standard for Terminal Instrument Procedures (TERPS). In developing these SIAPs and Takeoff Minimums and ODPs, the TERPS criteria were applied to the conditions existing or anticipated at the affected airports. Because of the close and immediate relationship between these SIAPs, Takeoff Minimums and ODPs, and safety in air commerce, I find that notice and public procedure under 
                    <PRTPAGE P="63282"/>
                    5 U.S.C. 553(b) are impracticable and contrary to the public interest and, where applicable, under 5 U.S.C. 553(d), good cause exists for making some SIAPs effective in less than 30 days.
                </P>
                <P>The FAA has determined that this regulation only involves an established body of technical regulations for which frequent and routine amendments are necessary to keep them operationally current. It, therefore—(1) is not a “significant regulatory action” under Executive Order 12866; (2) is not a “significant rule” under DOT Regulatory Policies and Procedures (44 FR 11034; February 26, 1979); and (3) does not warrant preparation of a regulatory evaluation as the anticipated impact is so minimal. For the same reason, the FAA certifies that this amendment will not have a significant economic impact on a substantial number of small entities under the criteria of the Regulatory Flexibility Act.</P>
                <LSTSUB>
                    <HD SOURCE="HED">Lists of Subjects in 14 CFR Part 97</HD>
                    <P>Air Traffic Control, Airports, Incorporation by reference, Navigation (Air).</P>
                </LSTSUB>
                <SIG>
                    <DATED>Issued in Washington, DC, on July 19, 2024.</DATED>
                    <NAME>Thomas J. Nichols,</NAME>
                    <TITLE>Standards Section Manager, Flight Procedures and Airspace Group, Flight Technologies and Procedures Division, Office of Safety Standards, Flight Standards Service, Aviation Safety, Federal Aviation Administration.</TITLE>
                </SIG>
                <HD SOURCE="HD1">Adoption of the Amendment</HD>
                <P>Accordingly, pursuant to the authority delegated to me, 14 CFR part 97 is amended by establishing, amending, suspending, or removing Standard Instrument Approach Procedures and/or Takeoff Minimums and Obstacle Departure Procedures effective at 0901 UTC on the dates specified, as follows:</P>
                <PART>
                    <HD SOURCE="HED">PART 97—STANDARD INSTRUMENT APPROACH PROCEDURES</HD>
                </PART>
                <REGTEXT TITLE="14" PART="97">
                    <AMDPAR>1. The authority citation for part 97 continues to read as follows:</AMDPAR>
                    <AUTH>
                        <HD SOURCE="HED">Authority:</HD>
                        <P>49 U.S.C. 106(f), 106(g), 40103, 40106, 40113, 40114, 40120, 44502, 44514, 44701, 44719, 44721-44722.</P>
                    </AUTH>
                </REGTEXT>
                <REGTEXT TITLE="14" PART="97">
                    <AMDPAR>2. Part 97 is amended to read as follows:</AMDPAR>
                    <EXTRACT>
                        <HD SOURCE="HD1">Effective 5 September 2024</HD>
                        <FP SOURCE="FP-1">Petersburg, AK, PAPG, PETERSBURG TWO, Graphic DP</FP>
                        <FP SOURCE="FP-1">Union Springs, AL, 07A, RNAV (GPS) RWY 14, Orig</FP>
                        <FP SOURCE="FP-1">Union Springs, AL, 07A, RNAV (GPS) RWY 32, Orig</FP>
                        <FP SOURCE="FP-1">Union Springs, AL, 07A, Takeoff Minimums and Obstacle DP, Orig</FP>
                        <FP SOURCE="FP-1">Porterville, CA, PTV, VOR-A, Orig</FP>
                        <FP SOURCE="FP-1">Porterville, CA, PTV, VOR OR GPS-A, Amdt 1A, CANCELED</FP>
                        <FP SOURCE="FP-1">Phillipsburg, KS, PHG, RNAV (GPS) RWY 13, Amdt 3</FP>
                        <FP SOURCE="FP-1">Phillipsburg, KS, KPHG, Takeoff Minimums and Obstacle DP, Amdt 2</FP>
                        <FP SOURCE="FP-1">Oakland, MD, 2G4, RNAV (GPS) RWY 9, Amdt 3</FP>
                        <FP SOURCE="FP-1">Oakland, MD, 2G4, RNAV (GPS) RWY 27, Amdt 3</FP>
                        <FP SOURCE="FP-1">Pellston, MI, PLN, ILS OR LOC RWY 32, Amdt 12</FP>
                        <FP SOURCE="FP-1">Pellston, MI, PLN, RNAV (GPS) RWY 32, Amdt 1</FP>
                        <FP SOURCE="FP-1">Aberdeen/Amory, MS, M40, VOR RWY 18, Amdt 7A, CANCELED</FP>
                        <FP SOURCE="FP-1">Bozeman, MT, BZN, ILS OR LOC RWY 12, Amdt 10</FP>
                        <FP SOURCE="FP-1">Harvard, NE, 08K, RNAV (GPS) RWY 17, Amdt 1</FP>
                        <FP SOURCE="FP-1">Harvard, NE, 08K, RNAV (GPS) RWY 35, Amdt 2</FP>
                        <FP SOURCE="FP-1">Kearney, NE, EAR, ILS OR LOC RWY 36, Amdt 4</FP>
                        <FP SOURCE="FP-1">Kearney, NE, EAR, RNAV (GPS) RWY 36, Amdt 3</FP>
                        <FP SOURCE="FP-1">Laconia, NH, LCI, RNAV (GPS) RWY 26, Orig-E</FP>
                        <FP SOURCE="FP-1">Tonopah, NV, TPH, VOR-A, Orig</FP>
                        <FP SOURCE="FP-1">Tonopah, NV, KTPH, VOR OR GPS-A, Amdt 3C, CANCELED</FP>
                        <FP SOURCE="FP-1">Yerington, NV, O43, RNAV (GPS) RWY 2, Orig</FP>
                        <FP SOURCE="FP-1">Yerington, NV, O43, Takeoff Minimums and Obstacle DP, Orig</FP>
                        <FP SOURCE="FP-1">Yerington, NV, KO43, YERINGTON ONE, Graphic DP</FP>
                        <FP SOURCE="FP-1">Fulton, NY, FZY, RNAV (GPS) RWY 24, Amdt 2</FP>
                        <FP SOURCE="FP-1">Montgomery, NY, MGJ, ILS OR LOC RWY 4, Orig-B</FP>
                        <FP SOURCE="FP-1">Cushing, OK, CUH, RNAV (GPS) RWY 18, Orig-A</FP>
                        <FP SOURCE="FP-1">Charleston, SC, CHS, VOR Y OR TACAN Y RWY 15, Amdt 14C</FP>
                        <FP SOURCE="FP-1">Houston, TX, SGR, RNAV (GPS) RWY 17, Amdt 3</FP>
                        <FP SOURCE="FP-1">Lampasas, TX, LZZ, RNAV (GPS) RWY 34, Amdt 1</FP>
                        <FP SOURCE="FP-1">Charlottesville, VA, CHO, ILS OR LOC RWY 3, Amdt 1C</FP>
                    </EXTRACT>
                </REGTEXT>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17117 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4910-13-P</BILCOD>
        </RULE>
        <RULE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF TRANSPORTATION</AGENCY>
                <SUBAGY>Federal Aviation Administration</SUBAGY>
                <CFR>14 CFR Part 97</CFR>
                <DEPDOC>[Docket No. 31558; Amdt. No. 4124]</DEPDOC>
                <SUBJECT>Standard Instrument Approach Procedures, and Takeoff Minimums and Obstacle Departure Procedures; Miscellaneous Amendments</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Federal Aviation Administration (FAA), DOT.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Final rule.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>This rule amends, suspends, or removes Standard Instrument Approach Procedures (SIAPs) and associated Takeoff Minimums and Obstacle Departure Procedures for operations at certain airports. These regulatory actions are needed because of the adoption of new or revised criteria, or because of changes occurring in the National Airspace System, such as the commissioning of new navigational facilities, adding new obstacles, or changing air traffic requirements. These changes are designed to provide for the safe and efficient use of the navigable airspace and to promote safe flight operations under instrument flight rules at the affected airports.</P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>This rule is effective August 5, 2024. The compliance date for each SIAP, associated Takeoff Minimums, and ODP is specified in the amendatory provisions.</P>
                    <P>The incorporation by reference of certain publications listed in the regulations is approved by the Director of the Federal Register as of August 5, 2024.</P>
                </EFFDATE>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>Availability of matter incorporated by reference in the amendment is as follows:</P>
                </ADD>
                <HD SOURCE="HD1">For Examination</HD>
                <P>1. U.S. Department of Transportation, Docket Ops-M30, 1200 New Jersey Avenue SE, West Bldg., Ground Floor, Washington, DC 20590-0001;</P>
                <P>2. The FAA Air Traffic Organization Service Area in which the affected airport is located;</P>
                <P>3. The office of Aeronautical Information Services, 6500 South MacArthur Blvd., Oklahoma City, OK 73169 or,</P>
                <P>4. The National Archives and Records Administration (NARA).</P>
                <P>
                    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>
                <HD SOURCE="HD1">Availability</HD>
                <P>
                    All SIAPs and Takeoff Minimums and ODPs are available online free of charge. Visit the National Flight Data Center online at 
                    <E T="03">nfdc.faa.gov</E>
                     to register. Additionally, individual SIAP and Takeoff Minimums and ODP copies may be obtained from the FAA Air Traffic Organization Service Area in which the affected airport is located.
                </P>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Thomas J. Nichols, Standards Section Manager, Flight Procedures and Airspace Group, Flight Technologies and Procedures Division, Office of Safety Standards, Flight Standards Service, Aviation Safety, Federal Aviation Administration. Mailing 
                        <PRTPAGE P="63283"/>
                        Address: FAA Mike Monroney Aeronautical Center, Flight Procedures and Airspace Group, 6500 South MacArthur Blvd., STB Annex, Bldg. 26, Room 217, Oklahoma City, OK 73099. Telephone: (405) 954-1139.
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    This rule amends 14 CFR part 97 by amending the referenced SIAPs. The complete regulatory description of each SIAP is listed on the appropriate FAA Form 8260, as modified by the National Flight Data Center (NFDC)/Permanent Notice to Air Missions (P-NOTAM), and is incorporated by reference under 5 U.S.C. 552(a), 1 CFR part 51, and 14 CFR 97.20. The large number of SIAPs, their complex nature, and the need for a special format make their verbatim publication in the 
                    <E T="04">Federal Register</E>
                     expensive and impractical. Further, pilots do not use the regulatory text of the SIAPs, but refer to their graphic depiction on charts printed by publishers of aeronautical materials. Thus, the advantages of incorporation by reference are realized and publication of the complete description of each SIAP contained on FAA form documents is unnecessary. This amendment provides the affected CFR sections, and specifies the SIAPs and Takeoff Minimums and ODPs with their applicable effective dates. This amendment also identifies the airport and its location, the procedure and the amendment number.
                </P>
                <HD SOURCE="HD1">Availability and Summary of Material Incorporated by Reference</HD>
                <P>
                    The material incorporated by reference is publicly available as listed in the 
                    <E T="02">ADDRESSES</E>
                     section.
                </P>
                <P>The material incorporated by reference describes SIAPs, Takeoff Minimums and ODPs as identified in the amendatory language for part 97 of this final rule.</P>
                <HD SOURCE="HD1">The Rule</HD>
                <P>This amendment to 14 CFR part 97 is effective upon publication of each separate SIAP and Takeoff Minimums and ODP as amended in the transmittal. For safety and timeliness of change considerations, this amendment incorporates only specific changes contained for each SIAP and Takeoff Minimums and ODP as modified by FDC permanent NOTAMs.</P>
                <P>The SIAPs and Takeoff Minimums and ODPs, as modified by FDC permanent NOTAM, and contained in this amendment are based on criteria contained in the U.S. Standard for Terminal Instrument Procedures (TERPS). In developing these changes to SIAPs and Takeoff Minimums and ODPs, the TERPS criteria were applied only to specific conditions existing at the affected airports. All SIAP amendments in this rule have been previously issued by the FAA in a FDC NOTAM as an emergency action of immediate flight safety relating directly to published aeronautical charts.</P>
                <P>The circumstances that created the need for these SIAP and Takeoff Minimums and ODP amendments require making them effective in less than 30 days.</P>
                <P>Because of the close and immediate relationship between these SIAPs, Takeoff Minimums and ODPs, and safety in air commerce, I find that notice and public procedure under 5 U.S.C. 553(b) are impracticable and contrary to the public interest and, where applicable, under 5 U.S.C. 553(d), good cause exists for making these SIAPs effective in less than 30 days.</P>
                <P>The FAA has determined that this regulation only involves an established body of technical regulations for which frequent and routine amendments are necessary to keep them operationally current. It, therefore—(1) is not a “significant regulatory action” under Executive Order 12866; (2) is not a “significant rule” under DOT regulatory Policies and Procedures (44 FR 11034; February 26, 1979); and (3) does not warrant preparation of a regulatory evaluation as the anticipated impact is so minimal. For the same reason, the FAA certifies that this amendment will not have a significant economic impact 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 97</HD>
                    <P>Air traffic control, Airports, Incorporation by reference, Navigation (air).</P>
                </LSTSUB>
                <SIG>
                    <DATED>Issued in Washington, DC, on July 19, 2024.</DATED>
                    <NAME>Thomas J. Nichols,</NAME>
                    <TITLE>Standards Section Manager, Flight Procedures and Airspace Group, Flight Technologies and Procedures Division, Office of Safety Standards, Flight Standards Service, Aviation Safety, Federal Aviation Administration.</TITLE>
                </SIG>
                <HD SOURCE="HD1">Adoption of the Amendment</HD>
                <P>Accordingly, pursuant to the authority delegated to me, 14 CFR part 97 is amended by amending Standard Instrument Approach Procedures and Takeoff Minimums and ODPs, effective at 0901 UTC on the dates specified, as follows:</P>
                <PART>
                    <HD SOURCE="HED">PART 97—STANDARD INSTRUMENT APPROACH PROCEDURES</HD>
                </PART>
                <REGTEXT TITLE="14" PART="97">
                    <AMDPAR>1. The authority citation for part 97 continues to read as follows:</AMDPAR>
                    <AUTH>
                        <HD SOURCE="HED">Authority:</HD>
                        <P>49 U.S.C. 106(f), 106(g), 40103, 40106, 40113, 40114, 40120, 44502, 44514, 44701, 44719, 44721-44722.</P>
                    </AUTH>
                </REGTEXT>
                <REGTEXT TITLE="14" PART="97">
                    <AMDPAR>2. Part 97 is amended to read as follows:</AMDPAR>
                    <P>By amending: § 97.23 VOR, VOR/DME, VOR or TACAN, and VOR/DME or TACAN; § 97.25 LOC, LOC/DME, LDA, LDA/DME, SDF, SDF/DME; § 97.27 NDB, NDB/DME; § 97.29 ILS, ILS/DME, MLS, MLS/DME, MLS/RNAV; § 97.31 RADAR SIAPs; § 97.33 RNAV SIAPs; and § 97.35 COPTER SIAPs, Identified as follows:</P>
                    <EXTRACT>
                        <HD SOURCE="HD2">* * * Effective Upon Publication</HD>
                    </EXTRACT>
                    <GPOTABLE COLS="7" OPTS="L2,tp0,i1" CDEF="xs48,xls24,r50,r75,10,10,xs120">
                        <TTITLE> </TTITLE>
                        <BOXHD>
                            <CHED H="1">AIRAC date</CHED>
                            <CHED H="1">State</CHED>
                            <CHED H="1">City</CHED>
                            <CHED H="1">Airport</CHED>
                            <CHED H="1">FDC No.</CHED>
                            <CHED H="1">FDC date</CHED>
                            <CHED H="1">Procedure name</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">5-Sep-24</ENT>
                            <ENT>SD</ENT>
                            <ENT>Sturgis</ENT>
                            <ENT>Sturgis Muni</ENT>
                            <ENT>4/0079</ENT>
                            <ENT>5/29/2024</ENT>
                            <ENT>RNAV (GPS) RWY 29, Amdt 1C.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">5-Sep-24</ENT>
                            <ENT>SD</ENT>
                            <ENT>Sturgis</ENT>
                            <ENT>Sturgis Muni</ENT>
                            <ENT>4/0080</ENT>
                            <ENT>5/29/2024</ENT>
                            <ENT>RNAV (GPS) RWY 11, Amdt 1C.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">5-Sep-24</ENT>
                            <ENT>MD</ENT>
                            <ENT>Churchville</ENT>
                            <ENT>Harford County</ENT>
                            <ENT>4/1108</ENT>
                            <ENT>6/20/2024</ENT>
                            <ENT>RNAV (GPS)-B, Orig-B.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">5-Sep-24</ENT>
                            <ENT>OK</ENT>
                            <ENT>Ketchum</ENT>
                            <ENT>South Grand Lake Rgnl</ENT>
                            <ENT>4/1716</ENT>
                            <ENT>6/24/2024</ENT>
                            <ENT>RNAV (GPS) RWY 36, Orig-C.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">5-Sep-24</ENT>
                            <ENT>OK</ENT>
                            <ENT>Ketchum</ENT>
                            <ENT>South Grand Lake Rgnl</ENT>
                            <ENT>4/1717</ENT>
                            <ENT>6/24/2024</ENT>
                            <ENT>RNAV (GPS) RWY 18, Orig-B.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">5-Sep-24</ENT>
                            <ENT>LA</ENT>
                            <ENT>Ruston</ENT>
                            <ENT>Ruston Rgnl</ENT>
                            <ENT>4/1732</ENT>
                            <ENT>6/24/2024</ENT>
                            <ENT>RNAV (GPS) RWY 18, Orig-D.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">5-Sep-24</ENT>
                            <ENT>ME</ENT>
                            <ENT>Greenville</ENT>
                            <ENT>Moosehead Aero Marine</ENT>
                            <ENT>4/2185</ENT>
                            <ENT>6/04/2024</ENT>
                            <ENT>RNAV (GPS)-B, Amdt 1.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">5-Sep-24</ENT>
                            <ENT>IN</ENT>
                            <ENT>Brazil</ENT>
                            <ENT>Brazil Clay County</ENT>
                            <ENT>4/2497</ENT>
                            <ENT>6/24/2024</ENT>
                            <ENT>RNAV (GPS) RWY 27, Orig-A.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">5-Sep-24</ENT>
                            <ENT>HI</ENT>
                            <ENT>Honolulu</ENT>
                            <ENT>Daniel K Inouye Intl</ENT>
                            <ENT>4/2946</ENT>
                            <ENT>5/15/2024</ENT>
                            <ENT>ILS RWY 8L, Amdt 25.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">5-Sep-24</ENT>
                            <ENT>MI</ENT>
                            <ENT>Iron Mountain Kingsford</ENT>
                            <ENT>Ford</ENT>
                            <ENT>4/3507</ENT>
                            <ENT>5/20/2024</ENT>
                            <ENT>RNAV (GPS) RWY 1, Orig-C.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">5-Sep-24</ENT>
                            <ENT>MI</ENT>
                            <ENT>Iron Mountain Kingsford</ENT>
                            <ENT>Ford</ENT>
                            <ENT>4/3508</ENT>
                            <ENT>5/20/2024</ENT>
                            <ENT>ILS OR LOC RWY 1, Amdt 13.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">5-Sep-24</ENT>
                            <ENT>AK</ENT>
                            <ENT>Deadhorse</ENT>
                            <ENT>Deadhorse</ENT>
                            <ENT>4/3923</ENT>
                            <ENT>6/26/2024</ENT>
                            <ENT>VOR RWY 6, Amdt 3.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">5-Sep-24</ENT>
                            <ENT>AK</ENT>
                            <ENT>Deadhorse</ENT>
                            <ENT>Deadhorse</ENT>
                            <ENT>4/3924</ENT>
                            <ENT>6/26/2024</ENT>
                            <ENT>VOR Z RWY 24, Amdt 5.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">5-Sep-24</ENT>
                            <ENT>WY</ENT>
                            <ENT>Hulett</ENT>
                            <ENT>Hulett Muni</ENT>
                            <ENT>4/4500</ENT>
                            <ENT>6/27/2024</ENT>
                            <ENT>RNAV (GPS)-A, Amdt 1B.</ENT>
                        </ROW>
                        <ROW>
                            <PRTPAGE P="63284"/>
                            <ENT I="01">5-Sep-24</ENT>
                            <ENT>MD</ENT>
                            <ENT>Friendly</ENT>
                            <ENT>Potomac Airfield</ENT>
                            <ENT>4/4529</ENT>
                            <ENT>6/28/2024</ENT>
                            <ENT>RNAV (GPS) RWY 6, Orig-A.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">5-Sep-24</ENT>
                            <ENT>OR</ENT>
                            <ENT>Baker City</ENT>
                            <ENT>Baker City Muni</ENT>
                            <ENT>4/4547</ENT>
                            <ENT>6/28/2024</ENT>
                            <ENT>RNAV (GPS) RWY 13, Amdt 2A.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">5-Sep-24</ENT>
                            <ENT>KS</ENT>
                            <ENT>Liberal</ENT>
                            <ENT>Liberal Mid-America Rgnl</ENT>
                            <ENT>4/5594</ENT>
                            <ENT>6/10/2024</ENT>
                            <ENT>RNAV (GPS) RWY 4, Orig-B.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">5-Sep-24</ENT>
                            <ENT>KS</ENT>
                            <ENT>Liberal</ENT>
                            <ENT>Liberal Mid-America Rgnl</ENT>
                            <ENT>4/5595</ENT>
                            <ENT>6/10/2024</ENT>
                            <ENT>RNAV (GPS) RWY 17, Orig-B.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">5-Sep-24</ENT>
                            <ENT>KS</ENT>
                            <ENT>Liberal</ENT>
                            <ENT>Liberal Mid-America Rgnl</ENT>
                            <ENT>4/5596</ENT>
                            <ENT>6/10/2024</ENT>
                            <ENT>RNAV (GPS) RWY 22, Amdt 1B.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">5-Sep-24</ENT>
                            <ENT>GA</ENT>
                            <ENT>Canton</ENT>
                            <ENT>Cherokee County Rgnl</ENT>
                            <ENT>4/5661</ENT>
                            <ENT>4/26/2024</ENT>
                            <ENT>RNAV (GPS) RWY 5, Amdt 1D.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">5-Sep-24</ENT>
                            <ENT>GA</ENT>
                            <ENT>Canton</ENT>
                            <ENT>Cherokee County Rgnl</ENT>
                            <ENT>4/5671</ENT>
                            <ENT>4/26/2024</ENT>
                            <ENT>RNAV (GPS) RWY 23, Amdt 1B.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">5-Sep-24</ENT>
                            <ENT>NE</ENT>
                            <ENT>Hartington</ENT>
                            <ENT>Hartington Muni/Bud Becker Fld</ENT>
                            <ENT>4/7503</ENT>
                            <ENT>5/22/2024</ENT>
                            <ENT>RNAV (GPS) RWY 13, Orig-D.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">5-Sep-24</ENT>
                            <ENT>GA</ENT>
                            <ENT>Vidalia</ENT>
                            <ENT>Vidalia Rgnl</ENT>
                            <ENT>4/8081</ENT>
                            <ENT>6/13/2024</ENT>
                            <ENT>ILS OR LOC RWY 25, Amdt 2A.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">5-Sep-24</ENT>
                            <ENT>TX</ENT>
                            <ENT>Granbury</ENT>
                            <ENT>Granbury Rgnl</ENT>
                            <ENT>4/8099</ENT>
                            <ENT>6/13/2024</ENT>
                            <ENT>RNAV (GPS) RWY 19, Orig.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">5-Sep-24</ENT>
                            <ENT>TX</ENT>
                            <ENT>Granbury</ENT>
                            <ENT>Granbury Rgnl</ENT>
                            <ENT>4/8101</ENT>
                            <ENT>6/13/2024</ENT>
                            <ENT>RNAV (GPS) RWY 1, Orig.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">5-Sep-24</ENT>
                            <ENT>LA</ENT>
                            <ENT>New Orleans</ENT>
                            <ENT>Louis Armstrong New Orleans Intl</ENT>
                            <ENT>4/8994</ENT>
                            <ENT>5/28/2024</ENT>
                            <ENT>ILS OR LOC RWY 11, ILS RWY 11 (SA CAT I), ILS RWY 11 (CAT II AND III), Amdt 5A.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">5-Sep-24</ENT>
                            <ENT>LA</ENT>
                            <ENT>New Orleans</ENT>
                            <ENT>Louis Armstrong New Orleans Intl</ENT>
                            <ENT>4/8995</ENT>
                            <ENT>5/28/2024</ENT>
                            <ENT>RNAV (RNP) Z RWY 11, Amdt 1B.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">5-Sep-24</ENT>
                            <ENT>LA</ENT>
                            <ENT>New Orleans</ENT>
                            <ENT>Louis Armstrong New Orleans Intl</ENT>
                            <ENT>4/8996</ENT>
                            <ENT>5/28/2024</ENT>
                            <ENT>RNAV (GPS) Y RWY 11, Amdt 2B.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">5-Sep-24</ENT>
                            <ENT>NE</ENT>
                            <ENT>Kearney</ENT>
                            <ENT>Kearney Rgnl</ENT>
                            <ENT>4/9022</ENT>
                            <ENT>5/20/2024</ENT>
                            <ENT>RNAV (GPS) RWY 18, Amdt 1.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">5-Sep-24</ENT>
                            <ENT>CA</ENT>
                            <ENT>Oxnard</ENT>
                            <ENT>Oxnard</ENT>
                            <ENT>4/9603</ENT>
                            <ENT>4/11/2024</ENT>
                            <ENT>VOR RWY 25, Amdt 10D.</ENT>
                        </ROW>
                    </GPOTABLE>
                </REGTEXT>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17118 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4910-13-P</BILCOD>
        </RULE>
        <RULE>
            <PREAMB>
                <AGENCY TYPE="N">DEPARTMENT OF HOMELAND SECURITY</AGENCY>
                <SUBAGY>Coast Guard</SUBAGY>
                <CFR>33 CFR Part 100</CFR>
                <DEPDOC>[Docket Number USCG-2024-0544]</DEPDOC>
                <RIN>RIN 1625-AA08</RIN>
                <SUBJECT>Special Local Regulation; Cayuga Lake, Ithaca, NY</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Coast Guard, DHS.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Temporary final rule.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Coast Guard is establishing a temporary special local regulation for certain waters of Cayuga Lake. This action is necessary to provide for the safety of life on these navigable waters near Ithaca, NY, during a marine event on August 10, 2024. This regulation prohibits persons and vessels from transiting the regulated area unless authorized by the Captain of the Port Sector Eastern Great Lakes or a designated representative.</P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>This rule is effective from 6 a.m. to 11:30 a.m. on August 10, 2024.</P>
                </EFFDATE>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        To view documents mentioned in this preamble as being available in the docket, go to 
                        <E T="03">https://www.regulations.gov,</E>
                         type USCG-2024-0544 in the search box and click “Search.” Next, in the Document Type column, select “Supporting &amp; Related Material.”
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        If you have questions about this rule, call or email MST1 Joseph Stranc, Waterways Management Division, U.S. Coast Guard Marine Safety Unit Thousand Islands; telephone 315-774-8724, email 
                        <E T="03">SMB-MSUThosandIslands-WaterwaysManagement@uscg.mil.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">I. Table of Abbreviations</HD>
                <EXTRACT>
                    <FP SOURCE="FP-1">CFR Code of Federal Regulations</FP>
                    <FP SOURCE="FP-1">DHS Department of Homeland Security</FP>
                    <FP SOURCE="FP-1">FR Federal Register</FP>
                    <FP SOURCE="FP-1">NPRM Notice of proposed rulemaking</FP>
                    <FP SOURCE="FP-1">§ Section </FP>
                    <FP SOURCE="FP-1">U.S.C. United States Code</FP>
                </EXTRACT>
                <HD SOURCE="HD1">II. Background Information and Regulatory History</HD>
                <P>March 4, 2024, an organization notified the Coast Guard that it will be conducting a swim event from 6 a.m. to 11:30 a.m. on August 10, 2024. The event will take place within the following boundaries: starting at point 42°30′07.01″ N, 076°30′57.04″ W; running adjacent shore to point 42°30′30.03″ N, 076°31′09.34″ W; thence to 42°29′50.20″ N, 076°32′24.99″ W; running adjacent to the shore to point 42°29′34.71″ N, 076°32′17.11″ W; thence back to starting position. In response, on July 10, 2024, the Coast Guard published a notice of proposed rulemaking (NPRM) titled Special Local Regulation; Cayuga Lake, Ithaca, NY 89 FR 56677. There we stated why we issued the NPRM and invited comments on our proposed regulatory action related to this fireworks display. During the comment period that ended July 25, 2024, we received no comments.</P>
                <P>
                    Under 5 U.S.C. 553(d)(3), the Coast Guard finds that good cause exists for making this rule effective less than 30 days after publication in the 
                    <E T="04">Federal Register</E>
                    . Delaying the effective date of this rule would be impracticable because immediate action is needed to ensure the safety for participants during the duration of the marine event.
                </P>
                <HD SOURCE="HD1">III. Legal Authority and Need for Rule</HD>
                <P>The Coast Guard is issuing this rule under authority in 46 U.S.C. 70041. The Captain of the Port Sector Eastern Great Lakes (COTP) has determined that potential hazards associated with the marine event occurring on August 10, 2024, will pose safety concern for the event participants. The purpose of this rule is to ensure safety of participants and the navigable waters in the regulated area before, during, and after the scheduled event.</P>
                <HD SOURCE="HD1">IV. Discussion of Comments, Changes, and the Rule</HD>
                <P>As noted above, we received no comments on our NPRM published July 10, 2024. There are no changes in the regulatory text of this rule from the proposed rule in the NPRM.</P>
                <P>
                    This rule establishes a special local regulation from 6 a.m. to 11:30 a.m. on August 10, 2024. The special local regulation will cover all navigable waters within Cayuga Lake starting at point 42°30′07.01″ N 076°30′57.04″ W and running adjacent to the shore to point 42°30′30.03″ N 076°31′09.34″ W, continuing to point 42°29′50.20″ N 076°32′24.99″ W, running adjacent to the shore to point 42°29′34.71″ N 076°32′17.11″ W, back to the starting position. The duration of the zone is intended to ensure the safety of event participants and these navigable waters before, during, and after the scheduled 6 a.m. to 11:30 a.m. marine event. No vessel or person will be permitted to enter the regulated area without 
                    <PRTPAGE P="63285"/>
                    obtaining permission from the COTP or a designated representative.
                </P>
                <HD SOURCE="HD1">V. Regulatory Analyses</HD>
                <P>We developed this rule after considering numerous statutes and Executive orders related to rulemaking. Below we summarize our analyses based on a number of these statutes and Executive orders, and we discuss First Amendment rights of protestors.</P>
                <HD SOURCE="HD2">A. Regulatory Planning and Review</HD>
                <P>Executive Orders 12866 and 13563 direct agencies to assess the costs and benefits of available regulatory alternatives and, if regulation is necessary, to select regulatory approaches that maximize net benefits. This rule has not been designated a “significant regulatory action,” under section 3(f) of Executive Order 12866, as amended by Executive Order 14094 (Modernizing Regulatory Review). Accordingly, this rule has not been reviewed by the Office of Management and Budget (OMB).</P>
                <P>This regulatory action determination is based on the size, location, duration and time of day of the regulated area. Vessel traffic would be able to safely transit through this regulated area which would impact a small designated area of Cayuga Lake for less than 6 hours during the morning. Moreover, the Coast Guard would issue a Broadcast Notice to Mariners via VHF-FM marine channel 16 about the regulated area, and the rule would allow vessels to seek permission to transit through the area.</P>
                <HD SOURCE="HD2">B. Impact on Small Entities</HD>
                <P>The Regulatory Flexibility Act of 1980, 5 U.S.C. 601-612, as amended, requires Federal agencies to consider the potential impact of regulations on small entities during rulemaking. The term “small entities” comprises small businesses, not-for-profit organizations that are independently owned and operated and are not dominant in their fields, and governmental jurisdictions with populations of less than 50,000. The Coast Guard received no comments from the Small Business Administration on this rulemaking. The Coast Guard certifies under 5 U.S.C. 605(b) that this rule will not have a significant economic impact on a substantial number of small entities.</P>
                <P>While some owners or operators of vessels intending to transit the regulated area may be small entities, for the reasons stated in section V.A above, this rule will not have a significant economic impact on any vessel owner or operator.</P>
                <P>
                    Under section 213(a) of the Small Business Regulatory Enforcement Fairness Act of 1996 (Pub. L. 104-121), we want to assist small entities in understanding this rule. If the rule would affect your small business, organization, or governmental jurisdiction and you have questions concerning its provisions or options for compliance, please call or email the person listed in the 
                    <E T="02">FOR FURTHER INFORMATION CONTACT</E>
                     section.
                </P>
                <P>Small businesses may send comments on the actions of Federal employees who enforce, or otherwise determine compliance with, Federal regulations to the Small Business and Agriculture Regulatory Enforcement Ombudsman and the Regional Small Business Regulatory Fairness Boards. The Ombudsman evaluates these actions annually and rates each agency's responsiveness to small business. If you wish to comment on actions by employees of the Coast Guard, call 1-888-REG-FAIR (1-888-734-3247). The Coast Guard will not retaliate against small entities that question or complain about this rule or any policy or action of the Coast Guard.</P>
                <HD SOURCE="HD2">C. Collection of Information</HD>
                <P>This rule will not call for a new collection of information under the Paperwork Reduction Act of 1995 (44 U.S.C. 3501-3520).</P>
                <HD SOURCE="HD2">D. Federalism and Indian Tribal Governments</HD>
                <P>A rule has implications for federalism under Executive Order 13132, Federalism, if it has a substantial direct effect on the States, on the relationship between the National Government and the States, or on the distribution of power and responsibilities among the various levels of government. We have analyzed this rule under that Order and have determined that it is consistent with the fundamental federalism principles and preemption requirements described in Executive Order 13132.</P>
                <P>Also, this rule does not have tribal implications under Executive Order 13175, Consultation and Coordination with Indian Tribal Governments, because it does not have a substantial direct effect on one or more Indian tribes, on the relationship between the Federal Government and Indian tribes, or on the distribution of power and responsibilities between the Federal Government and Indian tribes.</P>
                <HD SOURCE="HD2">E. Unfunded Mandates Reform Act</HD>
                <P>The Unfunded Mandates Reform Act of 1995 (2 U.S.C. 1531-1538) requires Federal agencies to assess the effects of their discretionary regulatory actions. In particular, the Act addresses actions that may result in the expenditure by a State, local, or tribal government, in the aggregate, or by the private sector of $100,000,000 (adjusted for inflation) or more in any one year. Though this rule will not result in such an expenditure, we do discuss the effects of this rule elsewhere in this preamble.</P>
                <HD SOURCE="HD2">F. Environment</HD>
                <P>
                    We have analyzed this rule under Department of Homeland Security Directive 023-01, Rev. 1, associated implementing instructions, and Environmental Planning COMDTINST 5090.1 (series), which guide the Coast Guard in complying with the National Environmental Policy Act of 1969 (42 U.S.C. 4321-4370f), and have determined that this action is one of a category of actions that do not individually or cumulatively have a significant effect on the human environment. This rule involves a special local regulation lasting 5.5 hours that would prohibit entry to the swim area of the Cayuga Lake without authorization from COTP or their designated representative. It is categorically excluded from further review under paragraph L61 of appendix A, Table 1 of DHS Instruction Manual 023-01-001-01, Rev. 1. A Memorandum for the Record supporting this determination is available in the docket. For instructions on locating the docket, see the 
                    <E T="02">ADDRESSES</E>
                     section of this preamble.
                </P>
                <HD SOURCE="HD2">G. Protest Activities</HD>
                <P>
                    The Coast Guard respects the First Amendment rights of protesters. Protesters are asked to call or email the person listed in the 
                    <E T="02">FOR FURTHER INFORMATION CONTACT</E>
                     section to coordinate protest activities so that your message can be received without jeopardizing the safety or security of people, places or vessels.
                </P>
                <LSTSUB>
                    <HD SOURCE="HED">List of Subjects in 33 CFR Part 100</HD>
                    <P>Marine safety, Navigation (water), Reporting and recordkeeping requirements, Waterways </P>
                </LSTSUB>
                <P>For the reasons discussed in the preamble, the Coast Guard amends 33 CFR part 100 as follows:</P>
                <PART>
                    <HD SOURCE="HED">PART 100—SAFETY OF LIFE ON NAVIGABLE WATERS</HD>
                </PART>
                <REGTEXT TITLE="33" PART="100">
                    <AMDPAR>1. The authority citation for part 100 continues to read as follows:</AMDPAR>
                    <AUTH>
                        <HD SOURCE="HED">Authority: </HD>
                        <P>46 U.S.C. 70041; 33 CFR 1.05-1.</P>
                    </AUTH>
                </REGTEXT>
                <REGTEXT TITLE="33" PART="100">
                    <AMDPAR>2. Add § 100.T999-0544 to read as follows:</AMDPAR>
                    <SECTION>
                        <PRTPAGE P="63286"/>
                        <SECTNO>§ 100.T999-0544 </SECTNO>
                        <SUBJECT>Women Swimmin' for Hospicare, Cayuga Lake, Ithaca, NY.</SUBJECT>
                        <P>
                            (a) 
                            <E T="03">Enforcement period.</E>
                             Coast Guard Sector Eastern Great Lakes Captain of the Port (COTP) will enforce this section from 6 a.m. to 11:30 a.m. on August 10, 2024, upon the navigable waters of Cayuga Lake as described in paragraph (b) of this section.
                        </P>
                        <P>
                            (b) 
                            <E T="03">Regulated area.</E>
                             The regulations in this section apply to the following area: All navigable waters within Cayuga Lake starting at point 42°30′07.01″ N 076°30′57.04″ W and running adjacent to the shore to point 42°30′30.03″ N 076°31′09.34″ W, continuing to point 42°29′50.20″ N 076°32′24.99″ W, running adjacent to the shore to point 42°29′34.71″ N 076°32′17.11″ W, back to the starting position.
                        </P>
                        <P>
                            (c) 
                            <E T="03">Definitions.</E>
                             As used in this section—
                        </P>
                        <P>
                            <E T="03">Designated representative</E>
                             means a Coast Guard Patrol Commander, including a Coast Guard coxswain, petty officer, or other officer operating a Coast Guard vessel and a Federal, State, and local officer designated by or assisting the COTP in the enforcement of the regulations in this section.
                        </P>
                        <P>
                            (d) 
                            <E T="03">Regulations.</E>
                             All vessels will be required to request permission from the COTP or their designated representative to transit the area and will operate at a no wake speed to reduce the wake to a minimum, and in a manner which will not endanger participants in the event or any other craft. The COTP or their designated representative may be contacted on Channel 16 (156.8 MHZ) by the call sign “Coast Guard Patrol Commander”.
                        </P>
                    </SECTION>
                </REGTEXT>
                <SIG>
                    <DATED>Dated: July 29, 2024.</DATED>
                    <NAME>S.M. Murray,</NAME>
                    <TITLE>Commander, U.S. Coast Guard, Alternate Captain of the Port, Sector Eastern Great Lakes. </TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17121 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 9110-04-P</BILCOD>
        </RULE>
        <RULE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF HOMELAND SECURITY</AGENCY>
                <SUBAGY>Coast Guard</SUBAGY>
                <CFR>33 CFR Part 165</CFR>
                <DEPDOC>[Docket Number USCG-2024-0607]</DEPDOC>
                <RIN>RIN 1625-AA87</RIN>
                <SUBJECT>Security Zone; Santa Monica Bay, Pacific Palisades, CA</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Coast Guard, DHS.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Temporary final rule.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Coast Guard is establishing a temporary security zone for certain waters of Santa Monica Bay. This action is necessary to provide for the security of life on these navigable waters near Will Rogers State Beach, Pacific Palisades, CA, during a beachfront event on August 11, 2024. This security zone would prohibit persons and vessels from being in the security zone unless authorized by the Captain of the Port Sector Los Angeles-Long Beach or a designated representative.</P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>This rule is effective from 7 a.m. to 7 p.m. on August 11, 2024.</P>
                </EFFDATE>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        To view documents mentioned in this preamble as being available in the docket, go to 
                        <E T="03">https://www.regulations.gov,</E>
                         type USCG-2024-0607 in the search box and click “Search.” Next, in the Document Type column, select “Supporting &amp; Related Material.”
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        If you have questions about this rule, call or email Lieutenant Commander Kevin Kinsella, Waterways Management Division Chief, U.S. Coast Guard; telephone 310-521-3860, email 
                        <E T="03">D11-SMB-SectorLALB-WWM@uscg.mil.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">I. Table of Abbreviations</HD>
                <EXTRACT>
                    <FP SOURCE="FP-1">CFR Code of Federal Regulations</FP>
                    <FP SOURCE="FP-1">DHS Department of Homeland Security</FP>
                    <FP SOURCE="FP-1">FR Federal Register</FP>
                    <FP SOURCE="FP-1">NPRM Notice of proposed rulemaking</FP>
                    <FP SOURCE="FP-1">§ Section </FP>
                    <FP SOURCE="FP-1">U.S.C. United States Code</FP>
                </EXTRACT>
                <HD SOURCE="HD1">II. Background Information and Regulatory History</HD>
                <P>The Coast Guard is issuing this temporary rule under authority in 5 U.S.C. 553(b)(B). This statutory provision authorizes an agency to issue a rule without prior notice and opportunity to comment when the agency for good cause finds that those procedures are “impracticable, unnecessary, or contrary to the public interest.” The Coast Guard finds that good cause exists for not publishing a notice of proposed rulemaking (NPRM) with respect to this rule because doing so is impracticable and contrary to the public interest. The Captain of the Port, Sector Los Angeles-Long Beach (COTP) was notified of the impending event with little notice and we lack sufficient time to issue a proposed rule and consider the comments before needing to address the potential safety hazardous associated with the nationalized event.</P>
                <P>
                    Also, under 5 U.S.C. 553(d)(3), the Coast Guard finds that good cause exists for making this rule effective less than 30 days after publication in the 
                    <E T="04">Federal Register</E>
                    . Delaying the effective date of this rule would be impracticable because prompt action is needed to respond to the potential safety and security hazards associated with the event.
                </P>
                <HD SOURCE="HD1">III. Legal Authority and Need for Rule</HD>
                <P>The Coast Guard is issuing this rule under authority in 46 U.S.C. 70124 and 70051. The COTP has determined that potential hazards associated with the beachfront event starting August 11, 2024, will be a safety concern for anyone within a 500-yard distance of the beachfront event before, during, and after the scheduled event. This rule is needed to protect personnel, vessels, and the marine environment in the navigable waters within the security zone while the event is taking place.</P>
                <HD SOURCE="HD1">IV. Discussion of the Rule</HD>
                <P>This rule establishes a security zone from 7 a.m. until 7 p.m. on August 11, 2024. The security zone will cover all navigable waters within 500 yards of the beachfront event on Will Rogers State Beach Pacific Palisades, CA between Lifeguard Stations 6 and 7. The duration of the zone is intended to ensure the security of personnel and these navigable waters before, during, and after the scheduled event. No vessel or person will be permitted to enter the security zone without obtaining permission from the COTP or a designated representative.</P>
                <HD SOURCE="HD1">V. Regulatory Analyses</HD>
                <P>We developed this rule after considering numerous statutes and Executive orders related to rulemaking. Below we summarize our analyses based on a number of these statutes and Executive orders, and we discuss First Amendment rights of protestors.</P>
                <HD SOURCE="HD2">A. Regulatory Planning and Review</HD>
                <P>Executive Orders 12866 and 13563 direct agencies to assess the costs and benefits of available regulatory alternatives and, if regulation is necessary, to select regulatory approaches that maximize net benefits. This rule has not been designated a “significant regulatory action,” under section 3(f) of Executive Order 12866, as amended by Executive Order 14094 (Modernizing Regulatory Review). Accordingly, this rule has not been reviewed by the Office of Management and Budget (OMB).</P>
                <P>
                    This regulatory action determination is based on size, location, duration, and time-of-day of the security zone. This security zone will encompass only 500 yards from the shore for a 12-hour period. Vessels will be able to transit 
                    <PRTPAGE P="63287"/>
                    around the security zone. Vessel operators may request permission to enter by contacting the COTP, and if allowed, must follow the directions of the COTP. Moreover, the Coast Guard would issue a Broadcast Notice to Mariners via VHF-FM marine channel 16 about the zone.
                </P>
                <HD SOURCE="HD2">B. Impact on Small Entities</HD>
                <P>The Regulatory Flexibility Act of 1980, 5 U.S.C. 601-612, as amended, requires Federal agencies to consider the potential impact of regulations on small entities during rulemaking. The term “small entities” comprises small businesses, not-for-profit organizations that are independently owned and operated and are not dominant in their fields, and governmental jurisdictions with populations of less than 50,000. The Coast Guard certifies under 5 U.S.C. 605(b) that this rule will not have a significant economic impact on a substantial number of small entities.</P>
                <P>While some owners or operators of vessels intending to transit the security zone may be small entities, for the reasons stated in section V.A above, this rule will not have a significant economic impact on any vessel owner or operator.</P>
                <P>
                    Under section 213(a) of the Small Business Regulatory Enforcement Fairness Act of 1996 (Pub. L. 104-121), we want to assist small entities in understanding this rule. If the rule would affect your small business, organization, or governmental jurisdiction and you have questions concerning its provisions or options for compliance, please call or email the person listed in the 
                    <E T="02">FOR FURTHER INFORMATION CONTACT</E>
                     section.
                </P>
                <P>Small businesses may send comments on the actions of Federal employees who enforce, or otherwise determine compliance with, Federal regulations to the Small Business and Agriculture Regulatory Enforcement Ombudsman and the Regional Small Business Regulatory Fairness Boards. The Ombudsman evaluates these actions annually and rates each agency's responsiveness to small business. If you wish to comment on actions by employees of the Coast Guard, call 1-888-REG-FAIR (1-888-734-3247). The Coast Guard will not retaliate against small entities that question or complain about this rule or any policy or action of the Coast Guard.</P>
                <HD SOURCE="HD2">C. Collection of Information</HD>
                <P>This rule will not call for a new collection of information under the Paperwork Reduction Act of 1995 (44 U.S.C. 3501-3520).</P>
                <HD SOURCE="HD2">D. Federalism and Indian Tribal Governments</HD>
                <P>A rule has implications for federalism under Executive Order 13132, Federalism, if it has a substantial direct effect on the States, on the relationship between the National Government and the States, or on the distribution of power and responsibilities among the various levels of government. We have analyzed this rule under that Order and have determined that it is consistent with the fundamental federalism principles and preemption requirements described in Executive Order 13132.</P>
                <P>Also, this rule does not have tribal implications under Executive Order 13175, Consultation and Coordination with Indian Tribal Governments, because it does not have a substantial direct effect on one or more Indian tribes, on the relationship between the Federal Government and Indian tribes, or on the distribution of power and responsibilities between the Federal Government and Indian tribes.</P>
                <HD SOURCE="HD2">E. Unfunded Mandates Reform Act</HD>
                <P>The Unfunded Mandates Reform Act of 1995 (2 U.S.C. 1531-1538) requires Federal agencies to assess the effects of their discretionary regulatory actions. In particular, the Act addresses actions that may result in the expenditure by a State, local, or tribal government, in the aggregate, or by the private sector of $100,000,000 (adjusted for inflation) or more in any one year. Though this rule will not result in such an expenditure, we do discuss the effects of this rule elsewhere in this preamble.</P>
                <HD SOURCE="HD2">F. Environment</HD>
                <P>
                    We have analyzed this rule under Department of Homeland Security Directive 023-01, Rev. 1, associated implementing instructions, and Environmental Planning COMDTINST 5090.1 (series), which guide the Coast Guard in complying with the National Environmental Policy Act of 1969 (42 U.S.C. 4321-4370f), and have determined that this action is one of a category of actions that do not individually or cumulatively have a significant effect on the human environment. This rule involves a security zone lasting only 12 hours that will prohibit entry within 500 yards of a beachfront evet. It is categorically excluded from further review under paragraph L60(a) of Appendix A, Table 1 of DHS Instruction Manual 023-01-001-01, Rev. 1. A Record of Environmental Consideration supporting this determination is available in the docket. For instructions on locating the docket, see the 
                    <E T="02">ADDRESSES</E>
                     section of this preamble.
                </P>
                <HD SOURCE="HD2">G. Protest Activities</HD>
                <P>
                    The Coast Guard respects the First Amendment rights of protesters. Protesters are asked to call or email the person listed in the 
                    <E T="02">FOR FURTHER INFORMATION CONTACT</E>
                     section to coordinate protest activities so that your message can be received without jeopardizing the safety or security of people, places, or vessels.
                </P>
                <LSTSUB>
                    <HD SOURCE="HED">List of Subjects in 33 CFR Part 165</HD>
                    <P>Harbors, Marine safety, Navigation (water), Reporting and recordkeeping requirements, Security measures, Waterways.</P>
                </LSTSUB>
                <P>For the reasons discussed in the preamble, the Coast Guard amends 33 CFR part 165 as follows:</P>
                <PART>
                    <HD SOURCE="HED">PART 165—REGULATED NAVIGATION AREAS AND LIMITED ACCESS AREAS</HD>
                </PART>
                <REGTEXT TITLE="33" PART="165">
                    <AMDPAR>1. The authority citation for part 165 continues to read as follows:</AMDPAR>
                    <AUTH>
                        <HD SOURCE="HED">Authority: </HD>
                        <P> 46 U.S.C. 70034, 70051, 70124; 33 CFR 1.05-1, 6.04-1, 6.04-6, and 160.5; Department of Homeland Security Delegation No. 00170.1, Revision No. 01.3.</P>
                    </AUTH>
                </REGTEXT>
                <REGTEXT TITLE="33" PART="165">
                    <AMDPAR>2. Add § 165.T11-0607 to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 165.T11-0607 </SECTNO>
                        <SUBJECT>Security Zone; Santa Monica Bay, Pacific Palisades, CA</SUBJECT>
                        <P>
                            (a) 
                            <E T="03">Location.</E>
                             The following area is a security zone: All waters of Santa Monica Bay, from surface to bottom, encompassed by a line connecting the following points beginning at 34°02.300′ N, 34°2.000′ N 118°32.033′ W, thence to 34°1.783′ N 118°32.183′ W, thence to 34°2.083′ N 118° 32.833′ W, and back to the beginning point. These coordinates are based on NAD 1983 Datum.
                        </P>
                        <P>
                            (b) 
                            <E T="03">Definitions.</E>
                             As used in this section, designated representative means a Coast Guard Patrol Commander, including a Coast Guard coxswain, petty officer, or other officer operating a Coast Guard vessel and a Federal, State, and local officer designated by or assisting the Captain of the Port Los Angeles-Long Beach (COTP) in the enforcement of the security zone.
                        </P>
                        <P>
                            (c) 
                            <E T="03">Regulations.</E>
                             (1) Under the general security zone regulations in subpart D of this part, you may not enter the security zone described in paragraph (a) of this section unless authorized by the COTP or the COTP's designated representative.
                        </P>
                        <P>
                            (2) To seek permission to enter, contact the COTP or the COTP's representative by VHF-FM Channel 13 (156.65 MHz) or 16 (156.8MHz). Those in the security zone must comply with 
                            <PRTPAGE P="63288"/>
                            all lawful orders or directions given to them by the COTP or the COTP's designated representative.
                        </P>
                        <P>
                            (d) 
                            <E T="03">Enforcement period.</E>
                             This security zone will be enforced from 7 a.m. to 7 p.m. on August 11, 2024.
                        </P>
                    </SECTION>
                </REGTEXT>
                <SIG>
                    <DATED>Dated: July 26, 2024.</DATED>
                    <NAME>S.L. Crecy,</NAME>
                    <TITLE>Captain, U.S. Coast Guard, Captain of the Port Sector Los Angeles-Long Beach.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17145 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 9110-04-P</BILCOD>
        </RULE>
        <RULE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF HOMELAND SECURITY</AGENCY>
                <SUBAGY>Coast Guard</SUBAGY>
                <CFR>33 CFR Part 165</CFR>
                <DEPDOC>[Docket Number USCG-2024-0679]</DEPDOC>
                <RIN>RIN 1625-AA00</RIN>
                <SUBJECT>Safety Zone; Port Huron Float Down, St. Clair River, Port Huron, MI</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Coast Guard, DHS.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Temporary final rule.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Coast Guard is establishing a temporary safety zone for navigable waters of the St. Clair River in the vicinity of Port Huron, MI. This zone is intended to restrict and control movement of vessels in a portion of the St. Clair River. Though this is an unsanctioned, non-permitted marine event, this zone is necessary to provide for the safety of life on the navigable waters during a float down event near Port Huron, MI.</P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>This rule is effective from 12 p.m. through 7 p.m. on August 18, 2024.</P>
                </EFFDATE>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        To view documents mentioned in this preamble as being available in the docket, go to 
                        <E T="03">https://www.regulations.gov,</E>
                         type USCG-2024-0679 in the “SEARCH” box and click “SEARCH.” Click on Open Docket Folder on the line associated with this rule.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        If you have questions on this rule, call or email Ms. Tracy Girard, U.S. Coast Guard; (313) 568-9564, 
                        <E T="03">Tracy.M.Girard@uscg.mil.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">I. Table of Abbreviations</HD>
                <EXTRACT>
                    <FP SOURCE="FP-1">CFR Code of Federal Regulations</FP>
                    <FP SOURCE="FP-1">DHS Department of Homeland Security</FP>
                    <FP SOURCE="FP-1">FR Federal Register</FP>
                    <FP SOURCE="FP-1">NPRM Notice of proposed rulemaking</FP>
                    <FP SOURCE="FP-1">§ Section </FP>
                    <FP SOURCE="FP-1">U.S.C. United States Code</FP>
                </EXTRACT>
                <HD SOURCE="HD1">II. Background Information and Regulatory History</HD>
                <P>During the afternoon of August 18, 2024, a non-sanctioned public event is scheduled to take place. The event is advertised over various social-media sites, in which a large number of persons float down a segment of the St. Clair River, using inner tubes and other similar floatation devices. The 2024 float down event will occur from approximately 12 p.m. through 7 p.m. on August 18, 2024. This non-sanctioned event has taken place on the third Sunday in August annually since 2009.</P>
                <P>No private or municipal entity requested a marine event permit from the Coast Guard for this event, and it has not received state or federal permits since its inception. The event has drawn over 5,000 participants of various ages annually. Despite plans put together by federal, state and local officials, emergency responders and law enforcement officials have been overburdened pursuing safety during this event. Medical emergencies, people drifting across the international border, and people trespassing on residential property when trying to get out of the water before the designated finish line are some of the numerous difficulties encountered during the float down event.</P>
                <P>During the 2014 float-down event, a 19-year-old participant died. During the 2016 float down, a wind shift caused thousands of U.S. citizen rafters with no passports to drift into Canadian waters. The current and wind made it impossible for the rafters to paddle back into U.S. waters, necessitating significant coordination with the Canadian authorities. Despite these events, promotional information for the event continues to be published. More than 5,000 people are again anticipated to float down the river this year. No public or private organization holds themselves responsible as the event sponsor.</P>
                <P>The Coast Guard is issuing this temporary rule without prior notice and opportunity to comment pursuant to authority under section 4(a) of the Administrative Procedure Act (APA) (5 U.S.C. 553(b)). This provision authorizes an agency to issue a rule without prior notice and opportunity to comment when the agency for good cause finds that those procedures are “impracticable, unnecessary, or contrary to the public interest.” Under 5 U.S.C. 553(b)(B), the Coast Guard finds that good cause exists for not publishing a notice of proposed rulemaking (NPRM) with respect to this rule because doing so is impracticable. The organizers of this event are very secretive, and careful not to be found out as the event has “no sponsor.” The Coast Guard could not receive notice of the float down with sufficient time to undergo notice and comment because the date of the event varies from year to year. The Coast Guard was not made aware the float down would occur in 2024 until there was insufficient time to allow for a comment period to run. We must establish this safety zone by August 18, 2024, in order to protect the public form, the hazards listed above associated with the float down.</P>
                <HD SOURCE="HD1">III. Legal Authority and Need for Rule</HD>
                <P>The Coast Guard is issuing this rule under authority in 46 U.S.C. 70034 (previously 33 U.S.C. 1231). The Captain of the Port Detroit (COTP) has determined the float down poses significant risk to public safety and property from 12 p.m. through 7 p.m. on August 18, 2024. The likely combination of large numbers of participants, strong river currents, limited rescue resources, and difficult emergency response scenarios could easily result in serious injuries or fatalities to float down participants and spectators. Therefore, the COTP is establishing a safety zone around the event location to help minimize risks to safety of life and property during this event.</P>
                <HD SOURCE="HD1">IV. Discussion of the Rule</HD>
                <P>
                    This rule establishes a safety zone from 12 p.m. through 7 p.m. on August 18, 2024. The safety zone will begin at Lighthouse Beach and encompass all U.S. waters of the St. Clair River bound by a line starting at a point on land north of Coast Guard Station Port Huron at position 43°00.416′ N; 082°25.333′ W, extending east to the international boundary to a point at position 43°00.416′ N; 082°25.033′ W, following south along the international boundary to a point at position 42°54.500′ N; 082°27.683′ W, extending west to a point on land just north of Stag Island at position 42°54.500′ N; 082°27.966′ W, and following north along the U.S. shoreline to the point of origin (WGS 84). No vessel or person will be permitted to enter the safety zone without obtaining permission from the COTP or a designated representative. Vessel operators must contact the COTP or his or her on-scene representative to obtain permission to transit through this safety zone. Additionally, no one under the age of 18 will be permitted to enter the safety zone if they are not wearing a Coast Guard approved personal floatation device. The COTP or his or 
                    <PRTPAGE P="63289"/>
                    her on-scene representative may be contacted via VHF Channel 16.
                </P>
                <HD SOURCE="HD1">V. Regulatory Analyses</HD>
                <P>We developed this rule after considering numerous statutes and Executive orders related to rulemaking. Below we summarize our analyses based on a number of these statutes and Executive orders, and we discuss First Amendment rights of protestors.</P>
                <HD SOURCE="HD2">A. Regulatory Planning and Review</HD>
                <P>Executive Orders 12866 and 13563 direct agencies to assess the costs and benefits of available regulatory alternatives and, if regulation is necessary, to select regulatory approaches that maximize net benefits. This rule has not been designated a “significant regulatory action,” under Executive Order 12866. Accordingly, this rule has not been reviewed by the Office of Management and Budget (OMB).</P>
                <P>This regulatory action determination is based on the size, location, duration, and time-of-day of the safety zone. Vessel traffic will not able to safely transit around this safety zone which will impact a designated area of the St. Clair River for 7 hours. Moreover, the Coast Guard would issue a Broadcast Notice to Mariners via VHF-FM marine channel 16 about the zone, and the rule would allow vessels to seek permission to enter the zone.</P>
                <HD SOURCE="HD2">B. Impact on Small Entities</HD>
                <P>The Regulatory Flexibility Act of 1980, 5 U.S.C. 601-612, as amended, requires Federal agencies to consider the potential impact of regulations on small entities during rulemaking. The term “small entities” comprises small businesses, not-for-profit organizations that are independently owned and operated and are not dominant in their fields, and governmental jurisdictions with populations of less than 50,000. The Coast Guard certifies under 5 U.S.C. 605(b) that this rule will not have a significant economic impact on a substantial number of small entities.</P>
                <P>While some owners or operators of vessels intending to transit the safety zone may be small entities, for the reasons stated in section V.A above, this rule will not have a significant economic impact on any vessel owner or operator.</P>
                <P>
                    Under section 213(a) of the Small Business Regulatory Enforcement Fairness Act of 1996 (Pub. L. 104-121), we want to assist small entities in understanding this rule. If the rule would affect your small business, organization, or governmental jurisdiction and you have questions concerning its provisions or options for compliance, please call or email the person listed in the 
                    <E T="02">FOR FURTHER INFORMATION CONTACT</E>
                     section.
                </P>
                <P>Small businesses may send comments on the actions of Federal employees who enforce, or otherwise determine compliance with, Federal regulations to the Small Business and Agriculture Regulatory Enforcement Ombudsman and the Regional Small Business Regulatory Fairness Boards. The Ombudsman evaluates these actions annually and rates each agency's responsiveness to small business. If you wish to comment on actions by employees of the Coast Guard, call 1-888-REG-FAIR (1-888-734-3247). The Coast Guard will not retaliate against small entities that question or complain about this rule or any policy or action of the Coast Guard.</P>
                <HD SOURCE="HD2">C. Collection of Information</HD>
                <P>This rule will not call for a new collection of information under the Paperwork Reduction Act of 1995 (44 U.S.C. 3501-3520).</P>
                <HD SOURCE="HD2">D. Federalism and Indian Tribal Governments</HD>
                <P>A rule has implications for federalism under Executive Order 13132, Federalism, if it has a substantial direct effect on the States, on the relationship between the National Government and the States, or on the distribution of power and responsibilities among the various levels of government. We have analyzed this rule under that Order and have determined that it is consistent with the fundamental federalism principles and preemption requirements described in Executive Order 13132.</P>
                <P>Also, this rule does not have tribal implications under Executive Order 13175, Consultation and Coordination with Indian Tribal Governments, because it does not have a substantial direct effect on one or more Indian tribes, on the relationship between the Federal Government and Indian tribes, or on the distribution of power and responsibilities between the Federal Government and Indian tribes.</P>
                <HD SOURCE="HD2">E. Unfunded Mandates Reform Act</HD>
                <P>The Unfunded Mandates Reform Act of 1995 (2 U.S.C. 1531-1538) requires Federal agencies to assess the effects of their discretionary regulatory actions. In particular, the Act addresses actions that may result in the expenditure by a State, local, or tribal government, in the aggregate, or by the private sector of $100,000,000 (adjusted for inflation) or more in any one year. Though this rule will not result in such an expenditure, we do discuss the effects of this rule elsewhere in this preamble.</P>
                <HD SOURCE="HD2">F. Environment</HD>
                <P>
                    We have analyzed this rule under Department of Homeland Security Directive 023-01, Rev. 1, associated implementing instructions, and Environmental Planning COMDTINST 5090.1 (series), which guide the Coast Guard in complying with the National Environmental Policy Act of 1969 (42 U.S.C. 4321-4370f), and have determined that this action is one of a category of actions that do not individually or cumulatively have a significant effect on the human environment. This rule involves a safety zone lasting 7 hours that will prohibit entry to a designated portion of the St. Clair River is categorically excluded from further review under paragraph L[60] of Appendix A, Table 1 of DHS Instruction Manual 023-01-001-01, Rev. 1. A Record of Environmental Consideration supporting this determination is available in the docket. For instructions on locating the docket, see the 
                    <E T="02">ADDRESSES</E>
                     section of this preamble.
                </P>
                <HD SOURCE="HD2">G. Protest Activities</HD>
                <P>
                    The Coast Guard respects the First Amendment rights of protesters. Protesters are asked to call or email the person listed in the 
                    <E T="02">FOR FURTHER INFORMATION CONTACT</E>
                     section to coordinate protest activities so that your message can be received without jeopardizing the safety or security of people, places or vessels.
                </P>
                <LSTSUB>
                    <HD SOURCE="HED">List of Subjects in 33 CFR Part 165</HD>
                    <P>Harbors, Marine safety, Navigation (water), Reporting and record keeping requirements, Security measures, Waterways.</P>
                </LSTSUB>
                <P>For the reasons discussed in the preamble, the Coast Guard amends 33 CFR part 165 as follows:</P>
                <PART>
                    <HD SOURCE="HED">PART 165—REGULATED NAVIGATION AREAS AND LIMITED ACCESS AREAS</HD>
                </PART>
                <REGTEXT TITLE="33" PART="165">
                    <AMDPAR>1. The authority citation for part 165 continues to read as follows:</AMDPAR>
                    <AUTH>
                        <HD SOURCE="HED">Authority: </HD>
                        <P>46 U.S.C. 70034, 70051, 70124; 33 CFR 1.05-1, 6.04-1, 6.04-6, and 160.5; Department of Homeland Security Delegation No. 00170.1, Revision No. 01.3.</P>
                    </AUTH>
                </REGTEXT>
                <REGTEXT TITLE="33" PART="165">
                    <AMDPAR>2. Add § 165.T09-0679 to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 165.T09-0679</SECTNO>
                        <SUBJECT> Safety Zones; Port Huron Float Down, St. Clair River, Port Huron, MI.</SUBJECT>
                        <P>
                            (a) 
                            <E T="03">Location.</E>
                             A safety zone is established to include all U.S. navigable waters of southern Lake Huron and the St. Clair River adjacent to Port Huron, 
                            <PRTPAGE P="63290"/>
                            MI, beginning at Lighthouse Beach and encompassing all U.S. waters of the St. Clair River bound by a line starting at a point on land north of Coast Guard Station Port Huron at position 43°00.416′ N; 082°25.333′ W, extending east to the international boundary to a point at position 43°00.416′ N; 082°25.033′ W, following south along the international boundary to a point at position 42°54.500′ N; 082°27.683′ W, extending west to a point on land just north of Stag Island at position 42°54.500′ N; 082°27.966′ W, and following north along the U.S. shoreline to the point of origin (NAD 83). (WGS 84).
                        </P>
                        <P>
                            (b) 
                            <E T="03">Enforcement period.</E>
                             The safety zone described in paragraph (a) will be enforced from 12 p.m. through 7 p.m. on August, 18, 2024..
                        </P>
                        <P>
                            (c) 
                            <E T="03">Regulations.</E>
                             (1) In accordance with the general regulations in § 165.23, entry into, transiting, or anchoring within the safety zones described in paragraph (a) is prohibited unless authorized by the COTP Detroit or a designated on-scene representative.
                        </P>
                        <P>(2) The safety zones are closed to all vessel traffic, except as may be permitted by the COTP Detroit or a designated on-scene representative.</P>
                        <P>(3) The “on-scene representative” of the COTP Detroit is any Coast Guard commissioned, warrant or petty officer or a federal, state, or local law enforcement officer designated by the COTP Detroit to act on his behalf.</P>
                        <P>(4) Vessel operators desiring to enter or operate within the safety zones must contact the COTP Detroit or an on-scene representative to obtain permission to do so. The COTP Detroit or an on-scene representative may be contacted via VHF Channel 16. Vessel operators given permission to enter or operate in the safety zone must comply with all directions given to them by the COTP Detroit or an on-scene representative.</P>
                    </SECTION>
                </REGTEXT>
                <SIG>
                    <DATED>Dated: July 30, 2024.</DATED>
                    <NAME>Richard P. Armstrong,</NAME>
                    <TITLE>Captain, U.S. Coast Guard, Captain of the Port Detroit.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17160 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 9110-04-P</BILCOD>
        </RULE>
        <RULE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF HOMELAND SECURITY</AGENCY>
                <SUBAGY>Coast Guard</SUBAGY>
                <CFR>33 CFR Part 165</CFR>
                <DEPDOC>[Docket No. USCG-2024-0660]</DEPDOC>
                <SUBJECT>Safety Zones; Recurring Safety Zones in Captain of the Port Northern Great Lakes Zone</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Coast Guard, DHS.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notification of enforcement of regulation.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Coast Guard will enforce various safety zones in August 2024 for marine events taking place in Captain of the Port Northern Great Lakes. Enforcement of these safety zones is necessary to protect the safety of life and property on the navigable waters immediately prior to, during, and immediately after events. During the period, the Coast Guard will enforce restrictions upon, and control movement of, vessels in a specified area immediately prior to, during, and immediately after events. During each enforcement period, vessels must stay out of the established safety zone and may only enter with permission from the Captain of the Port Northern Great Lakes or a designated representative.</P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>
                        The regulations listed in 33 CFR 165.918 will be enforced for the safety zones identified in the 
                        <E T="02">SUPPLEMENTARY INFORMATION</E>
                         section for the dates and times specified.
                    </P>
                </EFFDATE>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        If you have questions about this publication, call or email Waterways Management division, LT Rebecca Simpson, Coast Guard Sector Northern Great Lakes, U.S. Coast Guard; telephone 906-635-3223, email 
                        <E T="03">ssmprevention@uscg.mil.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>The Coast Guard will enforce the safety zones in 33 CFR 165.918 as per the time, dates, and locations indicated below:</P>
                <P>(1) Elk Rapids Harbor Days Fireworks (Elk Rapids, MI; East Arm Grand Traverse Bay, Lake Michigan) from 10:00 p.m. through 10:30 p.m. on August 3, 2024.</P>
                <P>(2) Nautical City Fireworks (Rogers City, MI; Lake Huron) from 10:00 p.m. through 10:30 p.m. on August 4, 2024. This notice also includes an alternative rain date from 10:00 p.m. through 10:30 p.m. on August 11, 2024.</P>
                <P>
                    This notice of enforcement is issued under authority of 33 CFR 165.918 and 5 U.S.C. 552 (a). In addition to this notice of enforcement in the 
                    <E T="04">Federal Register</E>
                    , the Coast Guard will provide the maritime community with advance notification of this enforcement period via Broadcast Notice to Mariners or Local Notice to Mariners. If the Captain of the Port Northern Great Lakes determines that the safety zone need not be enforced for the full duration stated in this notice, he or she may suspend such enforcement and notify the public of the suspension via Broadcast Notice to Mariners and grant general permission to enter the respective safety zone.
                </P>
                <SIG>
                    <DATED>Dated: July 30, 2024.</DATED>
                    <NAME>J.R. Bendle,</NAME>
                    <TITLE>Captain, U.S. Coast Guard, Captain of the Port Northern Great Lakes.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17158 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 9110-04-P</BILCOD>
        </RULE>
        <RULE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF HOMELAND SECURITY</AGENCY>
                <SUBAGY>Coast Guard</SUBAGY>
                <CFR>33 CFR Part 165</CFR>
                <DEPDOC>[Docket No. USCG-2023-0690]</DEPDOC>
                <RIN>RIN 1625-AA08</RIN>
                <SUBJECT>Special Local Regulations; Recurring Marine Events, Sector Key West, Update; Correction</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Coast Guard, DHS).</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Final rule; correcting amendment.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>
                        The Coast Guard published a document in the 
                        <E T="04">Federal Register</E>
                         on July 19, 2024, revising its existing regulations by updating the table for existing events in the Seventh Coast Guard District Captain of the Port (COTP) Key West. The document contained an incorrect footnote reference.
                    </P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Effective August 5, 2024.</P>
                </EFFDATE>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        If you have questions about this rule, call or email Lieutenant Hailye Wilson, Sector Key West, Waterways Management Division, Coast Guard; telephone 305-292-8768 (ext. 768), email 
                        <E T="03">Hailye.M.Wilson@uscg.mil.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>The document published on July 19, 2024, at FR doc. 2024-15552, contained an error in the regulatory text set out in instruction 2, revising section (b), in table 1 to 33 CFR 100.701. In section (b), in table 1 § 100.701, line number 4, column number 4, there is a footnote 1; however, there is no text for footnote 1. Reference to footnote 1 will be removed from the regulatory text.</P>
                <LSTSUB>
                    <PRTPAGE P="63291"/>
                    <HD SOURCE="HED">List of Subjects in 33 CFR Part 100</HD>
                    <P>Harbors, Marine Safety, Navigation (water), Reporting and Record keeping requirements, Security measures, Waterways.</P>
                </LSTSUB>
                <P>For the reasons discussed in the preamble, the Coast Guard amends 33 CFR part 100 as follows:</P>
                <PART>
                    <HD SOURCE="HED">PART 100—SAFETY OF LIFE ON NAVIGABLE WATERS</HD>
                </PART>
                <REGTEXT TITLE="33" PART="100">
                    <AMDPAR>1. The authority citation for part 100 continues to read as follows:</AMDPAR>
                    <AUTH>
                        <HD SOURCE="HED">Authority:</HD>
                        <P> 46 U.S.C. 70041; 33 CFR 1.05-1.</P>
                    </AUTH>
                </REGTEXT>
                <REGTEXT TITLE="33" PART="100">
                    <AMDPAR>2. In § 100.701, in table 1, under the heading “(b) COTP Zone Key West; Special Local Regulations,” revise entry 4. to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 100.701</SECTNO>
                        <SUBJECT> Special Local Regulations; Marine Events in the Seventh Coast Guard District.</SUBJECT>
                        <STARS/>
                        <GPOTABLE COLS="4" OPTS="L1,i1" CDEF="s50,r50,r50,r100">
                            <TTITLE>Table 1 to § 100.701</TTITLE>
                            <BOXHD>
                                <CHED H="1">Number/date</CHED>
                                <CHED H="1">Event</CHED>
                                <CHED H="1">Sponsor</CHED>
                                <CHED H="1">Location</CHED>
                            </BOXHD>
                            <ROW>
                                <ENT I="22"> </ENT>
                            </ROW>
                            <ROW>
                                <ENT I="28">*         *         *         *         *         *         *</ENT>
                            </ROW>
                            <ROW>
                                <ENT I="22"> </ENT>
                                <ENT O="xl"/>
                                <ENT>(b) COTP Zone Key West; Special Local Regulations</ENT>
                            </ROW>
                            <ROW>
                                <ENT I="22"> </ENT>
                            </ROW>
                            <ROW>
                                <ENT I="28">*         *         *         *         *         *         *</ENT>
                            </ROW>
                            <ROW>
                                <ENT I="01">4. One Saturday in September</ENT>
                                <ENT>Alligator Reef Lighthouse Swim</ENT>
                                <ENT>Friends of The Pool, Inc</ENT>
                                <ENT>Location(s) (Primary): Beginning at a point Latitude 24°54.82′ N, longitude 080°38.03′ W, thence to latitude 24°54.36′ N, longitude 080°37.72′ W, thence to latitude 24°51.07′ N, longitude 080°37.14′ W, thence to latitude 24°54.36′ N, longitude 080°37.72′ W, thence to point of origin at latitude 24°54.82′ N, longitude 080°38.03′ W. </ENT>
                            </ROW>
                            <ROW>
                                <ENT I="22"> </ENT>
                                <ENT O="xl"/>
                                <ENT O="xl"/>
                                <ENT>Location(s) (Alternate): Beginning at a point Latitude 24°54.82′ N, longitude 080°38.03′ W, thence to latitude 24°53.25′ N, longitude 080°37.04′ W, thence to latitude 24°52.05′ N, longitude 080°38.85′ W, thence to latitude 24°54.36′ N, longitude 080°37.72′ W, thence to point of origin at latitude 24°54.82′ N, longitude 080°38.03′ W.</ENT>
                            </ROW>
                            <ROW>
                                <ENT I="22"> </ENT>
                            </ROW>
                            <ROW>
                                <ENT I="28">*         *         *         *         *         *         *</ENT>
                            </ROW>
                        </GPOTABLE>
                    </SECTION>
                </REGTEXT>
                <SIG>
                    <DATED>Dated: July 30, 2024.</DATED>
                    <NAME>Michael T. Cunningham,</NAME>
                    <TITLE>Chief, Office of Regulations and Administrative Law, U.S. Coast Guard.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17183 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 9110-04-P</BILCOD>
        </RULE>
        <RULE>
            <PREAMB>
                <AGENCY TYPE="N">ENVIRONMENTAL PROTECTION AGENCY</AGENCY>
                <CFR>40 CFR Part 180</CFR>
                <DEPDOC>[EPA-HQ-OPP-2021-0232; FRL-12153-01-OCSPP]</DEPDOC>
                <SUBJECT>Potassium Carbonate; Exemption From the Requirement of a Tolerance</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Environmental Protection Agency (EPA).</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Final rule.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>This regulation establishes an exemption from the requirement of a tolerance for residues of potassium carbonate in or on all food commodities when used as a biochemical fungicide in accordance with label directions and good agricultural practices. Biofungitek, S.L. submitted a petition, pursuant to section 408(d) of the Federal Food, Drug, and Cosmetic Act (FFDCA), requesting an exemption from the requirement of a tolerance for the biochemical pesticide potassium carbonate. This regulation eliminates the need to establish a maximum permissible level for residues of potassium carbonate under FFDCA when used in accordance with this exemption.</P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>
                        This regulation is effective August 5, 2024. Objections and requests for hearings must be received on or before October 4, 2024 and must be filed in accordance with the instructions provided in 40 CFR part 178 (see also Unit I.C. of the 
                        <E T="02">SUPPLEMENTARY INFORMATION</E>
                        ).
                    </P>
                </EFFDATE>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        The docket for this action, identified by docket identification (ID) number EPA-HQ-OPP-2021-0232, is available at 
                        <E T="03">https://www.regulations.gov</E>
                         or at the Office of Pesticide Programs Regulatory Public Docket (OPP Docket) in the Environmental Protection Agency Docket Center (EPA/DC), West William Jefferson Clinton Bldg., Rm. 3334, 1301 Constitution Ave. NW, Washington, DC 20460-0001. The Public Reading Room is open from 8:30 a.m. to 4:30 p.m., Monday through Friday, excluding legal holidays. The telephone number for the Public Reading Room and for the OPP Docket is (202) 566-1744. Please review the visitor instructions and additional information about the docket available at 
                        <E T="03">https://www.epa.gov/dockets.</E>
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Chris Pfeifer, Biopesticides and Pollution Prevention Division (7511P), Office of Pesticide Programs, Environmental Protection Agency, 1200 Pennsylvania Ave. NW, Washington, DC 20460-0001; main telephone number: (202) 566-1599; email address: 
                        <E T="03">BPPDFRNotices@epa.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">I. General Information</HD>
                <HD SOURCE="HD2">A. Does this action apply to me?</HD>
                <P>You may be potentially affected by this action if you are an agricultural producer, food manufacturer, greenhouse owner, or pesticide manufacturer. The following list of North American Industrial Classification System (NAICS) codes is not intended to be exhaustive, but rather provides a guide to help readers determine whether this document applies to them. Potentially affected entities may include:</P>
                <P>
                    • Crop production (NAICS code 111).
                    <PRTPAGE P="63292"/>
                </P>
                <P>• Animal production (NAICS code 112).</P>
                <P>• Food manufacturing (NAICS code 311).</P>
                <P>• Pesticide manufacturing (NAICS code 32532).</P>
                <HD SOURCE="HD2">B. How can I get electronic access to other related information?</HD>
                <P>
                    You may access a frequently updated electronic version of 40 CFR part 180 through the Office of the Federal Register's e-CFR site at 
                    <E T="03">https://www.ecfr.gov/current/title-40.</E>
                </P>
                <HD SOURCE="HD2">C. How can I file an objection or hearing request?</HD>
                <P>Under FFDCA section 408(g), 21 U.S.C. 346a(g), any person may file an objection to any aspect of this regulation and may also request a hearing on those objections. You must file your objection or request a hearing on this regulation in accordance with the instructions provided in 40 CFR part 178. To ensure proper receipt by EPA, you must identify docket ID number EPA-HQ-OPP-2021-0232, in the subject line on the first page of your submission. All objections and requests for a hearing must be in writing and must be received by the Hearing Clerk on or before October 4, 2024. Addresses for mail and hand delivery of objections and hearing requests are provided in 40 CFR 178.25(b).</P>
                <P>In addition to filing an objection or hearing request with the Hearing Clerk as described in 40 CFR part 178, please submit a copy of the filing (excluding any Confidential Business Information (CBI)) for inclusion in the public docket. Information not marked confidential pursuant to 40 CFR part 2 may be disclosed publicly by EPA without prior notice. Submit the non-CBI copy of your objection or hearing request, identified by docket ID number EPA-HQ-OPP-2021-0232 by one of the following methods:</P>
                <P>
                    • 
                    <E T="03">Federal eRulemaking Portal: https://www.regulations.gov.</E>
                     Follow the online instructions for submitting comments. Do not submit electronically any information you consider to be CBI or other information whose disclosure is restricted by statute.
                </P>
                <P>
                    • 
                    <E T="03">Mail:</E>
                     OPP Docket, Environmental Protection Agency Docket Center (EPA/DC), (28221T), 1200 Pennsylvania Ave. NW, Washington, DC 20460-0001.
                </P>
                <P>
                    • 
                    <E T="03">Hand Delivery:</E>
                     To make special arrangements for hand delivery or delivery of boxed information, please follow the instructions at 
                    <E T="03">https://www.epa.gov/dockets/where-send-comments-epa-dockets.</E>
                </P>
                <P>
                    Additional instructions on commenting or visiting the docket, along with more information about dockets generally, is available at 
                    <E T="03">https://www.epa.gov/dockets.</E>
                </P>
                <HD SOURCE="HD1">II. Background and Statutory Findings</HD>
                <P>
                    In the 
                    <E T="04">Federal Register</E>
                     of June 1, 2021 (86 FR 29229) (FRL-10023-95), EPA issued a document pursuant to FFDCA section 408(d)(3), 21 U.S.C. 346a(d)(3), announcing the filing of a pesticide tolerance petition (PP 0F8851) by Biofungitek, S.L, Parque Científico y Tecnológico de Bizkaia, Astondo Bidea (Building 612), 48160 Derio, Spain (c/o Compliance Services International, 7501 Bridgeport Way West, Lakewood, WA 94899). The petition requested that 40 CFR part 180 be amended to establish an exemption from the requirement of a tolerance for residues of potassium carbonate, when used as a biochemical fungicide in or on all agricultural food commodities in accordance with label directions and good agricultural practices. That document referenced a summary of the petition prepared by Biofungitek, S.L., which is available in the docket at 
                    <E T="03">https://www.regulations.gov.</E>
                     No comments were received on the notice of filing.
                </P>
                <HD SOURCE="HD1">III. Aggregate Risk Assessment and Determination of Safety</HD>
                <P>Section 408(c)(2)(A)(i) of FFDCA allows EPA to establish an exemption from the requirement for a tolerance (the legal limit for a pesticide chemical residue in or on a food) only if EPA determines that the exemption is “safe.” Section 408(c)(2)(A)(ii) of FFDCA defines “safe” to mean that “there is a reasonable certainty that no harm will result from aggregate exposure to the pesticide chemical residue, including all anticipated dietary exposures and all other exposures for which there is reliable information.” This includes exposure through drinking water and in residential settings but does not include occupational exposure. Pursuant to FFDCA section 408(c)(2)(B), in establishing or maintaining in effect an exemption from the requirement of a tolerance, EPA must take into account the factors set forth in FFDCA section 408(b)(2)(C), which require EPA to give special consideration to exposure of infants and children to the pesticide chemical residue in establishing a tolerance and to “ensure that there is a reasonable certainty that no harm will result to infants and children from aggregate exposure to the pesticide chemical residue. . . .” Additionally, FFDCA section 408(b)(2)(D) requires that the Agency consider “available information concerning the cumulative effects of a particular pesticide's residues” and “other substances that have a common mechanism of toxicity.”</P>
                <P>EPA establishes exemptions from the requirement of a tolerance only in those cases where it can be clearly demonstrated that the risks from aggregate exposure to pesticide chemical residues under reasonably foreseeable circumstances will pose no harm to human health. If EPA is able to determine that a tolerance is not necessary to ensure that there is a reasonable certainty that no harm will result from aggregate exposure to the pesticide chemical residue, an exemption from the requirement of a tolerance may be established.</P>
                <P>Consistent with FFDCA section 408(c)(2)(A), and the factors specified in FFDCA section 408(c)(2)(B), EPA has reviewed the available scientific data and other relevant information in support of this action. EPA has sufficient data to assess the hazards of and to make a determination on aggregate exposure to potassium carbonate, including exposure resulting from the exemption established by this action. EPA's assessment of exposures and risks associated with potassium carbonate follows.</P>
                <HD SOURCE="HD2">A. Toxicological Profile</HD>
                <P>Potassium carbonate is a white, odorless solid that is classified as an inorganic salt. It is used as a leavening agent in pastas and breads, a pH adjustor for chocolate production, a buffering agent for making wine, and a dietary supplement in chicken feed. The Joint Food and Agriculture Organization of the United Nations (FAO)/World Health Organization (WHO) Expert Committee on Food Additives has determined that potassium carbonate has no limited terms for daily intake when used as a food additive (JFAO/WHO, 1966). Additionally, potassium carbonate has been granted “Generally Recognized as Safe” (GRAS) status for use as a food additive by the United States Food and Drug Administration (FDA) per 21 CFR 184.1613.</P>
                <P>
                    With regard to historical risk, humans have been regularly exposed to potassium carbonate in the environment without known incident. This naturally occurring inorganic salt is ubiquitous in the environment. Potassium carbonate is regularly found in soil, and is a primary constituent of potash, which has been used as a primary ingredient in ceramics, soaps and fertilizers since the Bronze Age. Currently, humans are also regularly exposed to potassium carbonate in cosmetics and foods without known toxic effects. Although humans are regularly exposed to this compound in the home and in the 
                    <PRTPAGE P="63293"/>
                    natural environment, sustained exposures of any significant concentration are unlikely in the environment, as this inorganic salt is extremely soluble, readily dissociating into nontoxic ions in the environment. Given humans' regular exposures to potassium carbonate without incident, its high solubility and its overall low toxicological profile, no significant risks are expected relative to any potential pesticidal exposures.
                </P>
                <P>As an active ingredient in pesticidal end-use products (EPs), potassium carbonate is a biochemical fungicide intended to be applied by spray to crops, turf and ornamentals in both agricultural and residential settings. Potential exposures to potassium carbonate are not expected to result in any risks of toxicological concern. Potassium carbonate is not expected to pose a risk through any pathways for the following reasons. (1) Potassium carbonate is highly water soluble and is expected to dissociate into nontoxic potassium and carbonate ions soon after any pesticidal application. (2) The human body has natural regulation mechanisms for dietarily processing the potassium and carbonate ions that comprise the salt, potassium carbonate. Specifically, the kidneys regulate the concentration of these ions; and excess ions are filtered out and excreted through urine. (3) Potassium and carbonate ions naturally occur and are already ubiquitous in the environment; and no significant increase in exposure to potassium and carbonate ions are expected relative to pesticidal use of potassium carbonate. (4) With regard to any potential oral toxicity, potassium carbonate showed low acute oral toxicity and no major adverse effects in the available subchronic oral toxicity database. (5) Based on the physicochemical properties, potassium carbonate degrades rapidly in the environment and is not anticipated to be present in any concentration outside potential naturally occurring background levels. (6) No toxicological endpoints have been identified for potassium carbonate. All the data submitted in support of the registration of this potassium carbonate confirm its low risk relative to any pesticidal exposures.</P>
                <P>With regard to the overall toxicological profile, potassium carbonate is of low toxicity through most routes of exposure.</P>
                <P>All acute toxicity data requirements for potassium carbonate were satisfied by either guideline studies or waiver rationales. The guideline studies submitted for potassium carbonate resulted in the active ingredient being classified as Toxicity Category IV for acute dermal and inhalation toxicity, and Toxicity Category III for acute oral toxicity. The data requirements for primary eye and dermal irritation were satisfied by rationales. The applicant observed that because potassium chloride as an inorganic salt has high pH, it is both is severely irritating and corrosive. In recognition of these physical-chemical characteristics, the applicant ascribed Toxicity Category I for both primary eye and primary dermal irritation. However, it must be noted that when potassium carbonate is added to the aqueous end-use product, which has been assessed as part of the assessment for potassium carbonate, the irritating effects are greatly diminished, and the primary eye and primary dermal irritation for that end-use product are Toxicity Category III. Lastly, available data indicate that potassium carbonate is not a skin sensitizer.</P>
                <P>All subchronic data requirements for the active ingredient potassium carbonate were satisfied with acceptable waiver rationales and a non-guideline study. The 90-day dermal toxicity and 90-day inhalation toxicity data requirements were satisfied by waiver rationales based primarily on low exposure and low toxicity. The subchronic oral toxicity data requirement was satisfied by a non-guideline subchronic oral toxicity repeat-dose oral 90-day dietary study using an acceptable surrogate salt, potassium bicarbonate.</P>
                <P>In the 90-day oral toxicity on potassium bicarbonate, rats were dosed at 1,480 and 3,130 mg/kg/day (males), and 1,660 and 3,530 mg/kg/day (females) in the diet. The feeding study resulted in a no observed adverse effect level (NOAEL) of 1,480 mg/kg/day in males and 1,660 mg/kg/day in female rats. The dose levels tested were well above the limit dose of 1,000 mg/kg/day. There were no treatment-related adverse effects on mortality, clinical signs, functional observational battery (FOB), body weight, body weight gain, food consumption, ophthalmoscopy, macroscopic findings, testosterone, follicle stimulating hormone, luteinizing hormone levels, organ weights, or histopathology.</P>
                <P>A waiver rationale for the 90-day dermal toxicity requirement was assessed by the Office of Pesticide Program's (OPP's) Hazard and Science Policy Council (HASPOC) using a weight of the evidence (WOE) approach that considered all of the available hazard and exposure information. The rationale for 90-day dermal toxicity was determined to be sufficient to satisfy the data requirement based on the following considerations: (1) potassium carbonate has been assigned Toxicity Category IV for acute dermal toxicity and is not a dermal sensitizer; (2) there were no adverse effects observed in the available repeat oral dose toxicity study with similar salts, including potassium bicarbonate; (3) humans have a history of exposure to potassium carbonate and similar carbonate salts without adverse reactions as seen in cosmetics and foods approved for use by the FDA; (4) the physical chemical properties of potassium carbonate such as high pH, high solubility in water, a low partition coefficient and low vapor pressure indicate a low probability for dermal penetration; (5) the carbonates and bicarbonates are recognized as GRAS by the FDA (21 CFR 184.1619) for use as flavoring agents; (6) potassium carbonate is approved for inert ingredient (buffering agent) use in pesticide products and has an exemption from the requirement of a tolerance (40 CFR 180.920) when applied to growing crops; (7) human health risk from occupational dermal exposure to the proposed pesticide product is expected to be comparatively minimal, as the maximum concentration reported in cosmetics is 93.4% (in rinse-off products), which already exceeds the product formulation concentration (58.04%) of the proposed EP prior to being further diluted into a spray solution; and (8) using a conservative dermal absorption estimate of 10% and an oral point of departure (POD) of 180 mg/kg/day, any potential exposure would be far below the limit dose of 1,000 mg/kg/day.</P>
                <P>
                    A waiver rationale for the 90-day inhalation toxicity requirement was assessed by the OPP's HASPOC using a WOE approach that considered all of the available hazard and exposure information. The rationale for 90-day inhalation toxicity was determined to be sufficient to satisfy the data requirement based on the following considerations: (1) the physical-chemical properties of potassium carbonate show negligible vapor pressure because it is a solid powder that dissociates into K
                    <SU>+</SU>
                     and CO
                    <E T="52">3</E>
                    <E T="51">2−</E>
                     ions when mixed with water; (2) the toxic effects of potassium carbonate are low based on the acute inhalation toxicity study (Toxicity Category IV); (3) during a non-guideline 21-day inhalation study for a potassium carbonate-based scrubbing solution, male and female rats dosed at 0.1, 0.2, and 0.4 mg/L showed no adverse systemic or neurotoxic effects; (4) no adverse effects or evidence of irritation were identified in the publicly available repeat-dose oral toxicity or 
                    <PRTPAGE P="63294"/>
                    developmental toxicity studies; and (5) although a qualitative risk assessment approach was taken, relevant margins of exposure (MOEs) were calculated from an oral POD of 180 mg/kg/day to represent worst-case scenarios. The occupational and residential handler MOEs ranged from 13,000 to 90,000,000 which are above 10X the Agency's Level of Concern (LOC) of 100.
                </P>
                <P>The data requirements for developmental toxicity were satisfied with the submission of four acceptable non-guideline developmental toxicity studies. No adverse effects on maternal or developmental parameters up to the highest doses tested were reported in the test ani. One developmental study administered potassium carbonate via oral gavage at 290 mg/kg/day to mice and at 180 mg/kg/day to rats. No discernible effects were observed on implantation, maternal or fetal survival; and no abnormalities were observed in soft or skeletal tissues. Another study using an accepted surrogate, potassium bicarbonate, was conducted on pregnant animals up to 330 mg/kg/day in rabbits, 340 mg/kg/day in rats, and 580 mg/kg/day in mice. No adverse effects were observed for any animals. In a third study, sodium carbonate, a carbonate which is significantly similar to potassium carbonate, was administered via oral gavage at dose levels up to 179 mg/kg/day in mice, 245 mg/kg/day in rats, and 340 mg/kg/day in rabbits with no adverse effects observed. In a fourth study, calcium carbonate, another carbonate which is significantly similar to potassium carbonate, was administered to rats up to 2,188 mg/kg/day in the diet showed no evidence of maternal toxicity or embryotoxic/teratogenic effects. In short, potassium carbonate is of low toxicity and significant exposure from use as a pesticide is not anticipated and, as such, is not expected to pose any risks with regard to developmental toxicity.</P>
                <P>
                    Genotoxicity and mutagenicity data requirements were satisfied through a variety of studies from the open scientific literature on potassium carbonate and similar carbonate/bicarbonate salts indicated that potassium carbonate and related carbonates are not genotoxic. (All the similar carbonate and bicarbonate salts referenced were determined to be acceptable surrogates as they were considered to be both structurally and functionally similar.) In a non-guideline Ames test, potassium carbonate tested negative and did not induce mutations in the 
                    <E T="03">Salmonella typhimurium</E>
                     strains TA92, TA1535, TA1000, TA 1537, TA94, and TA98 in the presence or absence of metabolic activation. In the same non-guideline report, potassium carbonate did not induce chromosome aberrations in a mammalian cell line (Chinese hamster fibroblasts) in the presence and absence of S9 metabolic activation. In another study, potassium bicarbonate and sodium bicarbonate, two carbonates considered similar to potassium carbonate, both tested negative and did not induce mutations in the 
                    <E T="03">S. typhimurium</E>
                     strains TA1535, TA1537, TA1538, TA98, and TA100 in the presence or absence of metabolic activation. An 
                    <E T="03">in vitro</E>
                     gene mutation guideline study in bacteria, showed calcium carbonate, another carbonate considered to be similar to potassium carbonate, was determined to be non-mutagenic to the 
                    <E T="03">S. typhimurium</E>
                     strains TA98, TA100, TA1535, and TA1537 and 
                    <E T="03">Escherichia coli</E>
                     WP2 uvrA with and without metabolic activation. Calcium carbonate did not induce chromosome aberrations in a mammalian cell line (L5178Y) in the presence or absence of S9 metabolic activation. Lastly, a guideline bacterial reverse mutation assay (OCSPP 870.5100) was submitted using potassium carbonate (MRID 50898908). In the guideline Ames test, potassium carbonate did not induce mutations in the 
                    <E T="03">S. typhimurium</E>
                     strains TA98, TA100, TA1535, TA 1537, and 
                    <E T="03">Escherichia coli</E>
                     WP2 uvrA in the presence or absence of metabolic activation. All submitted data indicate that potassium carbonate is non-genotoxic and non-mutagenic.
                </P>
                <HD SOURCE="HD2">B. Toxicological Points of Departure/Levels of Concern</HD>
                <P>No toxicological endpoints have been identified for potassium carbonate. The active ingredient is of low toxicity, and significant exposure is not expected based on the low application rates and rapid degradation in the environment.</P>
                <HD SOURCE="HD2">C. Exposure Assessment</HD>
                <P>
                    1. 
                    <E T="03">Dietary exposure from food, feed uses, and drinking water.</E>
                     As part of its qualitative risk assessment for potassium carbonate, the Agency considered the potential for dietary exposure to residues of the chemical. EPA concludes that dietary (food and drinking water) exposures are expected to be negligible, as significant residues of the substance are not anticipated on treated commodities at the time of consumption based on its physical and chemical properties. Foremost, potassium carbonate, an inorganic salt, is highly water soluble and is expected to dissociate into potassium and carbonate ions soon after any pesticidal application. Notably, potassium and carbonate ions naturally occur and are already ubiquitous in the environment; and no significant increase in exposure to potassium and carbonate ions are expected relative to the proposed use of the EP. Equally important, the human body has natural regulation mechanisms for potassium and carbonate ions that enter the body. The kidneys regulate the concentration of these ions; and excess ions are filtered out and excreted through urine. Minimal exposure and compensatory regulation notwithstanding, no dietary risks of concern are anticipated for any potential pesticidal exposure, as no toxicological endpoint of concern was identified for potassium carbonate through the oral route of exposure.
                </P>
                <P>
                    2. 
                    <E T="03">Non-dietary exposure.</E>
                     The term “residential exposure” is used in this document to refer to non-occupational, non-dietary exposure (
                    <E T="03">e.g.,</E>
                     textiles (clothing and diapers), carpets, swimming pools, and hard surface disinfection on walls, floors, tables). Potassium carbonate is intended for use in residential (non-occupational) settings. However, significant residential exposure is not expected because potassium carbonate is an inorganic ionic salt that does not easily volatilize and readily dissociates into potassium and carbonate ions in water. Both potassium and carbonate ions are ubiquitous in the environment; and data indicate that no significant increase in exposure to potassium carbonate is expected from use of potassium carbonate pesticide products. In addition, the ions K
                    <SU>+</SU>
                     and CO
                    <E T="52">3</E>
                    <E T="51">2−</E>
                     resulting from the ionization (dissociation) of K
                    <E T="52">2</E>
                    CO
                    <E T="52">3</E>
                     will not influence the natural K
                    <SU>+</SU>
                     or CO
                    <E T="52">3</E>
                    <E T="51">2−</E>
                     level in the body due to how the kidneys regulate the ion concentration found in the blood. Given the physicochemical properties and rapid dissociation of the ionic salt, residential handler and post-application exposures are not expected.
                </P>
                <P>
                    3. 
                    <E T="03">Cumulative effects from substances with a common mechanism of toxicity.</E>
                     Section 408(b)(2)(D)(v) of FFDCA requires that, when considering whether to establish, modify, or revoke a tolerance, the Agency consider “available information” concerning the cumulative effects of a particular pesticide's residues and “other substances that have a common mechanism of toxicity.” EPA has not found that potassium carbonate shares a common mechanism of toxicity with any other substances, and it does not appear to produce a toxic metabolite produced by other substances. For the purposes of this tolerance action, therefore, EPA has assumed potassium carbonate does not have a common mechanism of toxicity with other substances. For information regarding 
                    <PRTPAGE P="63295"/>
                    EPA's efforts to determine which chemicals have a common mechanism of toxicity and to evaluate the cumulative effects of such chemicals, see EPA's website at 
                    <E T="03">https://www.epa.gov/pesticide-science-and-assessing-pesticide-risks/cumulative-assessment-risk-pesticides.</E>
                </P>
                <HD SOURCE="HD2">D. Safety Factor for Infants and Children</HD>
                <P>FFDCA Section 408(b)(2)(C) provides that EPA shall retain an additional tenfold (10X) margin of safety for infants and children in the case of threshold effects to account for prenatal and postnatal toxicity and the completeness of the database on toxicity and exposure unless EPA determines based on reliable data that a different margin of safety will be safe for infants and children. This additional margin of safety is commonly referred to as the Food Quality Protection Act (FQPA) safety factor. In applying this provision, EPA either retains the default value of 10X, or uses a different additional safety factor when reliable data available to EPA support the choice of a different factor. An FQPA safety factor is not required at this time for potassium carbonate because no toxicological endpoints have been established and the qualitative risk assessment has concluded that Potassium Carbonate is of low toxicity and that no significant exposures are expected.</P>
                <HD SOURCE="HD2">E. Aggregate Risk</HD>
                <P>In accordance with the FFDCA, OPP must consider and aggregate (add) pesticide exposures and risks from three major sources: food, drinking water, and residential exposures. In an aggregate assessment, exposures from relevant sources that have the same toxicological endpoints are added together and compared to quantitative estimates of hazard, or the risks themselves can be aggregated. When aggregating exposures and risks from various sources, EPA considers both the route and duration of exposure. A qualitative aggregate risk assessment has been conducted for the proposed use of potassium carbonate based on the lack of identified endpoints in the toxicological database and minimal exposure to the active ingredient. No risks of concern have been identified.</P>
                <P>
                    A full explanation of the data upon which EPA relied and its risk assessment based on those data can be found within the May 31, 2023, document entitled “Product Chemistry Review and Human Health Risk Assessment for FIFRA Section 3 Registration of the Manufacturing-Use Product, Potassium Carbonate (99.5% Fine Powder) Containing Potassium Carbonate (99.5%) as its Active Ingredient.” This document, as well as other relevant information, is available in the docket for this action as described under 
                    <E T="02">ADDRESSES</E>
                    .
                </P>
                <HD SOURCE="HD1">IV. Determination of Safety for U.S. Population, Infants and Children</HD>
                <P>Based on the Agency's assessment, EPA concludes that there is reasonable certainty that no harm will result to the U.S. population, including infants and children, from aggregate exposure to residues of potassium carbonate.</P>
                <HD SOURCE="HD1">V. Other Considerations</HD>
                <HD SOURCE="HD2">Analytical Enforcement Methodology</HD>
                <P>An analytical method is not required for enforcement purposes since the Agency is establishing an exemption from the requirement of a tolerance without any numerical limitation.</P>
                <HD SOURCE="HD1">VI. Conclusion</HD>
                <P>Therefore, EPA is establishing an exemption from the requirement of a tolerance for residues of potassium carbonate in or on all food commodities when used as a biochemical fungicide in accordance with label directions and good agricultural practices.</P>
                <HD SOURCE="HD1">VII. Statutory and Executive Order Reviews</HD>
                <P>
                    This action establishes an exemption from the requirement of a tolerance under FFDCA section 408(d) in response to a petition submitted to the Agency. The Office of Management and Budget (OMB) has exempted these types of actions from review under Executive Order 12866, entitled “Regulatory Planning and Review” (58 FR 51735, October 4, 1993). Because this action has been exempted from review under Executive Order 12866, this action is not subject to Executive Order 13211, entitled “Actions Concerning Regulations That Significantly Affect Energy Supply, Distribution, or Use” (66 FR 28355, May 22, 2001), or Executive Order 13045, entitled “Protection of Children from Environmental Health Risks and Safety Risks” (62 FR 19885, April 23, 1997). This action does not contain any information collections subject to OMB approval under the Paperwork Reduction Act (PRA), 44 U.S.C. 3501 
                    <E T="03">et seq.,</E>
                     nor does it require any special considerations under Executive Order 12898, entitled “Federal Actions to Address Environmental Justice in Minority Populations and Low-Income Populations” (59 FR 7629, February 16, 1994).
                </P>
                <P>
                    Since tolerances and exemptions that are established on the basis of a petition under FFDCA section 408(d), such as the exemption in this final rule, do not require the issuance of a proposed rule, the requirements of the Regulatory Flexibility Act (RFA) (5 U.S.C. 601 
                    <E T="03">et seq.</E>
                    ), do not apply.
                </P>
                <P>
                    This action directly regulates growers, food processors, food handlers, and food retailers, not States or Tribes, nor does this action alter the relationships or distribution of power and responsibilities established by Congress in the preemption provisions of FFDCA section 408(n)(4). As such, the Agency has determined that this action will not have a substantial direct effect on States or Tribal governments, on the relationship between the National Government and the States or Tribal governments, or on the distribution of power and responsibilities among the various levels of government or between the Federal Government and Indian Tribes. Thus, the Agency has determined that Executive Order 13132, entitled “Federalism” (64 FR 43255, August 10, 1999), and Executive Order 13175, entitled “Consultation and Coordination with Indian Tribal Governments” (65 FR 67249, November 9, 2000), do not apply to this action. In addition, this action does not impose any enforceable duty or contain any unfunded mandate as described under Title II of the Unfunded Mandates Reform Act (UMRA) (2 U.S.C. 1501 
                    <E T="03">et seq.</E>
                    ).
                </P>
                <P>This action does not involve any technical standards that would require Agency consideration of voluntary consensus standards pursuant to section 12(d) of the National Technology Transfer and Advancement Act (NTTAA) (15 U.S.C. 272 note).</P>
                <HD SOURCE="HD1">VIII. Congressional Review Act</HD>
                <P>
                    Pursuant to the Congressional Review Act (5 U.S.C. 801 
                    <E T="03">et seq.</E>
                    ), EPA will submit a report containing this rule and other required information to the U.S. Senate, the U.S. House of Representatives, and the Comptroller General of the United States prior to publication of the rule in the 
                    <E T="04">Federal Register</E>
                    . This action is not a “major rule” as defined by 5 U.S.C. 804(2).
                </P>
                <LSTSUB>
                    <HD SOURCE="HED">List of Subjects in 40 CFR Part 180</HD>
                    <P>Environmental protection, Administrative practice and procedure, Agricultural commodities, Pesticides and pests, Reporting and recordkeeping requirements.</P>
                </LSTSUB>
                <SIG>
                    <PRTPAGE P="63296"/>
                    <DATED>Dated: July 29, 2024.</DATED>
                    <NAME>Edward Messina,</NAME>
                    <TITLE>Director, Office of Pesticide Programs.</TITLE>
                </SIG>
                <P>Therefore, for the reasons stated in the preamble, EPA is amending 40 CFR chapter I as follows:</P>
                <PART>
                    <HD SOURCE="HED">PART 180—TOLERANCES AND EXEMPTIONS FOR PESTICIDE CHEMICAL RESIDUES IN FOOD</HD>
                </PART>
                <REGTEXT TITLE="40" PART="180">
                    <AMDPAR>1. The authority citation for part 180 continues to read as follows:</AMDPAR>
                    <AUTH>
                        <HD SOURCE="HED">Authority: </HD>
                        <P>21 U.S.C. 321(q), 346a and 371.</P>
                    </AUTH>
                </REGTEXT>
                <REGTEXT TITLE="40" PART="180">
                    <AMDPAR>2. Add § 180.1413 to subpart D to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 180.1413</SECTNO>
                        <SUBJECT> Potassium Carbonate; exemption from the requirement of a tolerance.</SUBJECT>
                        <P>An exemption from the requirement of a tolerance is established for residues of potassium carbonate in or on all food commodities when used as a biochemical fungicide in or on all agricultural food commodities in accordance with label directions and good agricultural practices.</P>
                    </SECTION>
                </REGTEXT>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17003 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6560-50-P</BILCOD>
        </RULE>
        <RULE>
            <PREAMB>
                <AGENCY TYPE="N">FEDERAL COMMUNICATIONS COMMISSION</AGENCY>
                <CFR>47 CFR Parts 0, 1, 2, and 26</CFR>
                <DEPDOC>[ET Docket No. 13-115; RM-11341; FCC 23-76; FR ID 234720]</DEPDOC>
                <SUBJECT>Allocation of Spectrum for Non-Federal Space Launch Operations; Federal Earth Stations Communicating With Non-Federal Fixed Satellite Service Space Stations; and Federal Space Station Use of the 399.9-400.05 MHz Band</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Federal Communications Commission.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Final rule.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>In this document, the Federal Communications Commission (Commission) adopts a new secondary allocation in the 2025-2110 MHz band for non-Federal space operations, removes the restriction on use of the 2200-2290 MHz secondary non-Federal space operation allocation to four specific sub-channels to make the entire 2200-2290 MHz band available, adds a non-Federal secondary mobile allocation to the 2200-2290 MHz band, and adopts licensing and technical rules for space launch operations. Additionally, the Commission amends the allocation for the 399.9-400.05 MHz band to permit the deployment of Federal space stations.</P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P/>
                    <P>
                        <E T="03">Effective date:</E>
                         Effective September 4, 2024, except for amendatory instructions 10 through 13 (adding §§ 26.106, 26.108, 26.202, and 26.301, respectively), which are delayed indefinitely. The Commission will publish a document in the 
                        <E T="04">Federal Register</E>
                         announcing the effective date.
                    </P>
                    <P>
                        <E T="03">Incorporation by reference:</E>
                         The incorporation by reference of certain material listed herein is approved by the Director of the Federal Register as of September 4, 2024.
                    </P>
                </EFFDATE>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Nicholas Oros of the Office of Engineering and Technology, at 
                        <E T="03">Nicholas.Oros@fcc.gov</E>
                         or 202-418-0636; Linda Chang of the Wireless Telecommunications Bureau at 
                        <E T="03">Linda.Chang@fcc.gov</E>
                         or 202-418-1339; or Julia Malette of the Space Bureau, at 
                        <E T="03">Julia.Malette@fcc.gov</E>
                         or 202-418-2453. For information regarding the Paperwork Reduction Act (PRA) information requirements contained in this document, contact Nicole Ongele, Office of Managing Director, at (202) 418-2991 or 
                        <E T="03">Nicole.Ongele@fcc.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    This is a summary of the Commission's 
                    <E T="03">Second Report and Order,</E>
                     in ET Docket No. 13-115; RM-11341; FCC 23-76, adopted on September 21, 2023, and released on September 22, 2023. The full text of this document is available for public inspection and can be downloaded at: 
                    <E T="03">https://docs.fcc.gov/public/attachments/FCC-23-76A1.pdf.</E>
                     Alternative formats are available for people with disabilities (Braille, large print, electronic files, audio format) by sending an email to 
                    <E T="03">FCC504@fcc.gov</E>
                     or calling the Commission's Consumer and Governmental Affairs Bureau at (202) 418-0530 (voice), (202) 418-0432 (TTY).
                </P>
                <HD SOURCE="HD1">Procedural Matters</HD>
                <P>
                    <E T="03">Final Regulatory Flexibility Analysis.</E>
                     The Regulatory Flexibility Act of 1980 (RFA) requires that an agency prepare a regulatory flexibility analysis for notice and comment rulemakings, unless the agency certifies that “the rule will not, if promulgated, have a significant economic impact on a substantial number of small entities.” Accordingly, the Commission has prepared a Final Regulatory Flexibility Analysis (FRFA) concerning the possible impact of the rule changes contained in the 
                    <E T="03">Second Report and Order</E>
                     on small entities. The FRFA is set forth in  Appendix B of the FCC document, 
                    <E T="03">https://docs.fcc.gov/public/attachments/FCC-23-76A1.pdf.</E>
                </P>
                <P>
                    <E T="03">Paperwork Reduction Act.</E>
                     The 
                    <E T="03">Second Report and Order</E>
                     contains new information collection requirements subject to the Paperwork Reduction Act of 1995 (PRA), Public Law 104-13. It will be submitted to the Office of Management and Budget (OMB) for review under section 3507(d) of the PRA. OMB, the general public, and other Federal agencies will be invited to comment on the new or modified information collection requirements contained in this proceeding. In addition, the Commission notes that pursuant to the Small Business Paperwork Relief Act of 2002, Public Law 107-198, 
                    <E T="03">see</E>
                     44 U.S.C. 3506(c)(4), the Commission previously sought specific comment on how it might further reduce the information collection burden for small business concerns with fewer than 25 employees.
                </P>
                <P>
                    <E T="03">Congressional Review Act.</E>
                     The Commission has determined, and the Administrator of the Office of Information and Regulatory Affairs, Office of Management and Budget, concurs, that this rule is non-major under the Congressional Review Act, 5 U.S.C. 804(2). The Commission will send a copy of the 
                    <E T="03">Second Report and Order</E>
                     to Congress and the Government Accountability office, pursuant to 5 U.S.C. 801(a)(1)(A).
                </P>
                <P>
                    <E T="03">Accessing Materials.</E>
                     The Office of Federal Register (OFR) regulations require that agencies must discuss in the preamble of a final rule the ways that the materials incorporated by reference are reasonably available to interested parties and where interested parties can obtain the materials. In addition, OFR regulations require that the preamble of a final rule summarizes the material incorporated by reference.
                </P>
                <P>
                    Section 26.302(a) and (b) of the regulations adopted herein incorporate by reference Annex J, Guidance for Determination of Necessary Bandwidth, and Annex M, Measurement Standards, of the National Telecommunications and Information Administration (NTIA) Manual of Regulations and Procedures for Federal Radio Frequency Management (NTIA Manual), January 2023 Revision (of the January 2021 Edition). The information in these annexes provide guidance for determining the necessary bandwidth and the measurement requirements for the unwanted emission mask of space launch radiocommunication systems. Interested parties may inspect a copy of the NTIA Manual at the FCC's main office, 45 L Street NE, Washington, DC 20554; email: 
                    <E T="03">oetinfo@fcc.gov.</E>
                     The NTIA Manual is also available online at 
                    <E T="03">https://www.ntia.gov/publications/redbook-manual.</E>
                    <PRTPAGE P="63297"/>
                </P>
                <HD SOURCE="HD1">Synopsis</HD>
                <P>As discussed in greater detail below, the Commission continues its efforts to provide regulatory certainty and additional spectrum to promote innovation and investment in the United States commercial space launch industry.</P>
                <HD SOURCE="HD1">Non-Federal Allocations for the 420-430 MHz, 2025-2110 MHz, 2200-2290 MHz, and 5650-5925 MHz Bands</HD>
                <P>Taking into account the record, the Commission finds sufficient support and justification for adopting an allocation for the 2025-2110 MHz band and expanding the previously adopted 2200-2290 MHz band allocation. Given that use of the 420-430 MHz, 2360-2395 MHz, and 5650-5925 MHz bands remains limited, the Commission is not convinced there is need for new allocations for any of these bands at this time.</P>
                <P>
                    <E T="03">Allocation for the 420-430 MHz band.</E>
                     The 420-430 MHz band is used during launches from Federal launch sites to transmit a flight termination signal to a launch vehicle, resulting in its self-destruction if necessary. While there was support on the record for adding this allocation, commenters differed in their suggested use of the band. Boeing suggest that the Commission restrict use of the band to only pre-launch testing and launches to prevent ancillary uses from interfering with safety-of-life transmissions. The United Launch Alliance (ULA), the Aerospace Industries Association (AIA), and the Industry Coalition Response (ICR), however, support flexible use of the band beyond the proposed self-destruct transmissions. Federal incumbents in the band also had differing opinions on adding the allocation to the band. The National Aeronautics and Space Administration (NASA) supports the allocation, if use of the band is limited and Federal incumbents are properly protected. The Department of Defense (DoD) does not oppose adopting such an allocation; however it recognizes that high power radar systems across the country could interfere with the reception of termination signals.
                </P>
                <P>The Commission concludes not to adopt a primary non-Federal Aeronautical Mobile allocation for the 420-430 MHz band. The FCC has not received any special temporary authorities (STAs) to use this band during space launches, as most current launch facilities have Federal systems in place for flight-termination purposes. Additionally, as ULA correctly observes, alternative flight-termination solutions for errant launches are already being implemented. For these reasons, and in light of the present and potential future limitations on use of the band raised by commenters, the Commission is not adopting the proposed allocation.</P>
                <P>
                    <E T="03">Allocation for the 2025-2110 MHz band.</E>
                     The 2025-2110 MHz band is currently allocated for both Federal and non-Federal fixed and mobile uses. The Broadcast Auxiliary Service (BAS) makes up most of the non-Federal use of the band and share the band with the Cable Television Relay Service (CARS) and the Local Television Transmission Service (LTTS). The band is also allocated on a primary basis for Federal space operation, Earth exploration satellite, and space research uses. While Federal use of the band is allocated on a co-primary basis, Federal use must not constrain BAS, CARS, and LTTS deployment. The 2025-2110 MHz band also includes primary Federal fixed and mobile allocations with use restricted to the military services, in order to facilitate relocation of military operations from the 1755-1780 MHz band. Federal use of the band has continued to increase, but coordination with non-Federal users has been successful. This success is due in large part to the memorandum of understanding (MOU) created by broadcast incumbents and the Federal users. The Commission has issued many STAs in this band allowing space launch operations to transmit control signals to launch vehicles. The further notice of proposed rulemaking (
                    <E T="03">FNPRM</E>
                    ) (86 FR 30860, June 10, 2021) sought comment on adding a co-primary non-Federal space operation (Earth-to-space) allocation to the 2025-2110 MHz band, in order to provide the space launch industry's increased use of the band with regulatory certainty.
                </P>
                <P>There was overwhelming support on the record for adopting the proposed allocation. While there was disagreement on the type of restrictions that should be adopted, all commenters were in agreement that any potential space launch operations in the band must be coordinated with all incumbents. According to NTIA, given the important missions of Federal agencies in the band it is important for all Federal users to maintain priority and for all commercial launches to remain subject to prior coordination.</P>
                <P>
                    The Commission concludes that adopting a non-Federal secondary allocation for space launch operations with the same coordination requirements that currently apply to Federal users will sufficiently address the regulatory needs of the commercial space launch industry while ensuring the protection of incumbents. This spectrum is regularly used by commercial space launch providers and granting regulatory certainty will boost investment and promote innovation in this industry. Adopting this allocation will eliminate the time and expense required for seeking STAs, which also often lapse due to the need to reschedule launches, thus requiring multiple STAs per launch. Based on the Commission's experience with STAs in this band, the Commission believes the existing coordination requirements, already proven to facilitate frequency re-use and coordination, will sufficiently protect incumbents and readily grant launch providers access to spectrum. The Commission appreciates the concerns raised by the Federal agencies and are following their suggestion to adopt a secondary allocation instead of a primary allocation as proposed. While Federal space operations have primary allocation status, the restrictions on Federal operations to protect the long-established BAS and CARS licensees in the band in effect relegate the Federal space launch activities as secondary to these Commission licensees. As the commercial space launch providers will also have to coordinate with these terrestrial licensees, a secondary allocation appears to be more appropriate at this time. The coordination framework currently in place for Federal space operations has permitted a high degree of spectrum efficiency and reuse for non-Federal and Federal operations. Adopting a secondary non-Federal Space Operation allocation for the 2025-2110 MHz band will allow the Commission to develop effective rules for the space launch industry, no longer requiring the lengthy experimental rules process. Hence, the Commission is implementing this secondary non-Federal Space Operation (Earth-to-space) allocation to the 2025-2110 MHz band in the U.S. Table. This allocation will be limited to space launch telecommand transmissions and will require commercial space launch providers to coordinate with non-Federal terrestrial licensees (
                    <E T="03">i.e.,</E>
                     BAS, LTTS, and CARS) and NTIA.
                </P>
                <P>
                    While there was support on the record for making the band available for use for on-orbit service (OOS) and rendezvous and proximity operations (RPO), the Commission agrees with Boeing that the increased use of the band from the ongoing relocation of Federal operations provides reason to exercise caution in authorizing any additional non-Federal space operations. The Commission therefore will address these operations through separate actions, taking into 
                    <PRTPAGE P="63298"/>
                    account also the record developed in response to the Commission's Notice of Inquiry on In-space Servicing, Assembly, and Manufacturing (ISAM) (87 FR 56365, September 14, 2022). The Commission also does not agree with the National Association of Broadcasters (NAB) and Society of Broadcast Engineers, Inc. (SBE) that space launch operations in the band should be limited to specified geographic sites because the coordination requirement the Commission is adopting will ensure BAS, LTTS, CARS licensees in all geographic areas are protected from harmful interference.
                </P>
                <P>
                    <E T="03">Allocation for the 2200-2290 MHz Band.</E>
                     The 2200-2290 MHz band is used for launch telemetry—
                    <E T="03">i.e.,</E>
                     sending diagnostic information from the space launch vehicle to ground controller stations during the launch to allow tracking of the performance of the launch vehicle. The 2200-2290 MHz band is heavily used by DoD and other Federal agencies and has primary Federal Space Operation, Earth Exploration Satellite, Fixed, Mobile, and Space Research allocations. The 
                    <E T="03">Report and Order</E>
                     (86 FR 33902, June 28, 2021) added a non-Federal secondary Space Operation (space-to-Earth) allocation to the band. Use of this allocation is limited by an Allocation Table footnote to pre-launch testing and space launch operations and coordination with NTIA is required prior to each launch. In addition, non-Federal space operations are restricted to the 2208.5-2213.5 MHz, 2212.5-2217.5 MHz, 2270-2275 MHz, and 2285-2290 MHz portions of the band.
                </P>
                <P>
                    The 
                    <E T="03">FNPRM</E>
                     proposed to remove the restriction on non-Federal use of the new Space Operation allocation to the four sub-bands and asked whether non-Federal use of the band should continue to be limited to channels with a necessary bandwidth of 5 megahertz. The 
                    <E T="03">FNPRM</E>
                     also sought comment on upgrading the secondary Space Operations allocation to a primary allocation noting that this would place commercial launch operators on an equal footing with other users of the band and provide greater certainty to incentivize investment as the commercial space industry continues to expand with more frequent launches, privately developed launch facilities, and manned space flights. The 
                    <E T="03">FNPRM</E>
                     also sought comment on adding a secondary Mobile allocation to the 2200-2290 MHz band and whether use of the Mobile allocation should be subject to the same restrictions that apply to the non-Federal Space Operations allocation for the band and whether it should be subject to the same restrictions that apply to Federal users—
                    <E T="03">i.e.,</E>
                     should it be restricted to line-of-sight use only, exclude flight testing of manned aircraft, and prohibit the introduction of high-density mobile systems.
                </P>
                <P>
                    The 
                    <E T="03">FNPRM</E>
                     noted that use of the secondary Space Operation allocation for the band is limited compared to what would normally be permitted under a Space Operation allocation. The Space Operation Service is defined in the Commission's rules as being “concerned exclusively with the operation of spacecraft, in particular space tracking, space telemetry, and space telecommand.”
                </P>
                <P>Comments from the commercial space industry overwhelmingly support removal of the restrictions on non-Federal use of the band for launch operations. However, Boeing expressed some reservations. Federal agencies such as NASA, DoD, and the Department of Commerce (DoC) strongly oppose any changes to the restrictions on non-Federal use of the band. NTIA states that expanding the scope of non-Federal use of the band would worsen coordination efforts in an already heavily congested band. The Federal agencies also did not support upgrading the secondary non-Federal Space Operation allocation to primary status.</P>
                <P>The Commission concludes that it is appropriate to provide commercial space launch operators with access to a greater portion of the 2200-2290 MHz band beyond the four sub-bands currently provided. Most of the STAs that the Commission has issued for space launch telemetry in this band have regularly included use of channels that are outside of these four sub-channels. As all of these STAs have been coordinated with NTIA this indicates that coordination of use of channels outside of these sub-bands is achievable and that limiting use of 2200-2290 MHz for commercial space launches to these sub-bands does not fully meet the needs of the commercial space launch industry. Therefore, the Commission is removing the restriction of use of the non-Federal space operation allocation to the four sub-bands.</P>
                <P>However, the Commission will not upgrade the secondary non-Federal Space Operation allocation for the 2200-2290 MHz band to a primary allocation. When the Commission adopted the current secondary allocation for the band, the Commission noted that this would accomplish many of the goals it had sought to accomplish with the proposed primary allocation such as enabling the Commission to adopt service rules and issue spectrum authorizations, reduce the uncertainty of the launch-by-launch STA process, and permit the development of well-defined technical rules that licensees can design equipment to comply with. The Commission noted that even if it had adopted a primary non-Federal allocation for this band, individual launches would still need to be coordinated because of the heavy existing Federal use of the band. The Commission continues to believe for these same reasons that the current secondary allocation will meet the needs of the commercial space industry. The Commission is cognizant of the complications of sharing this band with the large number of Federal operations and the expressed preference of Federal agencies to maintain the current secondary allocation. In recognition of the need to work closely with the Commission's Federal partners in managing the use of this band, the Commission finds that maintaining the current secondary allocation as advised by NTIA is appropriate at this time.</P>
                <P>The Commission will add a secondary Mobile allocation to the band. Providing this Mobile allocation will facilitate the Commission adopting technical rules for space launch telemetry that follow the same approach that NTIA applies to Federal launches. NTIA treats telemetry systems during the first stage of a launch as an aeronautical mobile system and the second and later stages as a space operation system. Because many launch vehicles are used for both Federal and non-Federal launches and many non-Federal launches occur at Federal launch facilities, the Commission believes it is important to have the flexibility to adopt technical rules that are in harmony with the technical standards applied to Federal launches. The secondary Mobile allocation the Commission is adopting for this band will be subject to the same restrictions as the non-Federal Space Operation allocation in the band. The non-Federal Mobile allocation will be restricted to use during pre-launch testing and space launch operations and subject to coordination for each launch. The only opposition to adding a Mobile allocation to the band came from Boeing, who expressed concern that adopting the Mobile allocation would prompt interest in making the band available for 5G and other future mobile services. Given the heavy restrictions on non-Federal use of this band the Commission does not agree with Boeing that it will be considered a candidate for commercial mobile use.</P>
                <P>
                    The Commission will not remove the current limitation on use of the non-Federal Space Operation allocation to 
                    <PRTPAGE P="63299"/>
                    pre-launch testing and space launch operations at this time. The heavy use of the band by Federal agencies necessitates that the Commission takes a cautious approach to making provisions for additional use cases of this band. While several commenters such as Northup Grumman and Axiom expressed interest in using this band for on-orbit activities, the record is sparse as to the technical details of these types of operations. The Commission does not currently have the information needed to reach a conclusion as to the impact of these operations on Federal users of the band.
                </P>
                <P>
                    <E T="03">Allocation for the 5650-5925 MHz Band.</E>
                     The 5650-5925 MHz band is used for radar tracking of launch vehicles. During a launch, a radar transponder located on the launch vehicle is typically used to transmit tracking information down to the tracking station. A primary Federal allocation limits use of radiolocation services to military operations. Prior space launches that have used this band have relied on Federal facilities to provide tracking for launches occurring at Federal ranges. The band is also used by Unlicensed National Information Infrastructure (U-NII) devices operating under the Commission's part 15 rules. The 5850-5925 MHz portion of the band has a primary non-Federal Mobile allocation limited to the Intelligent Transportation System radio service. While commercial use of the band remained limited at the time, the 
                    <E T="03">FNPRM</E>
                     sought comment on whether to adopt a non-Federal Radiolocation allocation for the 5650-5925 MHz band by adding a footnote to the U.S. Table. Of the few comments addressing this topic, there was no consensus on the record for adopting this allocation.
                </P>
                <P>
                    Based on the record, the Commission concludes not to adopt a non-Federal Radiolocation allocation for the 5650-5925 MHz band. While there was support for adding the allocation from some commercial space launch entities, interest in using the band remains low. Commenters failed to provide information on the number of launches likely to need access to this band in the future or other information requested in the 
                    <E T="03">FNPRM.</E>
                     In recent years only a small number of launches have obtained access to this band for radar transponders using STAs. As there has been limited use of this band in the past and the Commission has no reason to believe this will change in the future, there is no clear need to adopt this allocation. If space launch operators need access to this band for radar transponders, they may continue to use the STA process.
                </P>
                <HD SOURCE="HD1">Licensing and Technical Rules for Space Launch Operations</HD>
                <P>
                    The Commission also adopts rules for the new commercial Space Launch Services. These rules flexibly, efficiently, and effectively support the evolving spectrum requirements of commercial space launch operations while continuing to protect vital Federal operations in the 2025-2110 MHz and 2200-2290 MHz bands. The Commission installs a licensing framework that will grant nationwide, non-exclusive licenses to non-Federal entities that conduct space launch operations in the 2025-2110 MHz and 2200-2290 MHz bands. The Commission also adds a new part 26 to its rules that codifies the rules the Commission adopts in the 
                    <E T="03">Second Report and Order</E>
                     for space launch operations as well as any related rules that it may adopt in the future for other types of space activities. In addition, the Commission adopts rules defining the scope of the service it establishes in the 
                    <E T="03">Second Report and Order,</E>
                     as well as the types of entities that will be eligible to hold licenses in the new commercial Space Launch Services. Finally, the Commission adopts specific licensing rules governing shared frequency use, authorized bandwidth, license term and renewal, application processing rules, and coordination requirements, as well as technical rules that will foster interoperability of equipment used for non-Federal and Federal launches and rules regarding equipment authorization. In doing so, the Commission recognizes that licensee pre-launch coordination with NTIA may necessitate additional requirements and limitations on non-Federal launch operations in specific instances, in addition to those it establishes here.
                </P>
                <HD SOURCE="HD1">Licensing Rules for Space Launch Operations</HD>
                <HD SOURCE="HD2">Creation of New Rule Part 26</HD>
                <P>The Commission creates a new rule part 26 for the new commercial space launch service. The record regarding the question of where to incorporate the rules for space launch operations is mixed, due largely to varying opinions as to the activities that should be included in a space launch operation. The Commission agrees with commenters who argue that a standalone rule part is more efficient and flexible than regulating commercial space launch operations under existing rule parts.</P>
                <P>
                    The Commission finds that locating rules into a new part will provide greater clarity and ease of reference regarding commercial space launch operations. Establishing a rule part specific to these operations rather than placing rules in existing rule parts appears more appropriate given that launch operations, while having elements applicable to parts 87 and 25 depending on the launch, do not fall completely under either one. Creating a new rule part is also forward-looking; as discussed 
                    <E T="03">infra,</E>
                     while the rules the Commission is adopting here are specific to launch operations, it is seeking additional comment in another rulemaking proceeding on measures that the Commission can take to facilitate more routine licensing for certain payload and space operations. The use of a standalone rule part therefore could be used to accommodate rules relating to other types of space activities to the extent the Commission adopts rules regarding such operations. Accordingly, the Commission finds it appropriate to establish a new part 26.
                </P>
                <P>
                    <E T="03">Issues Overlapping with ISAM Proceeding.</E>
                     In the 
                    <E T="03">FNPRM,</E>
                     the Commission asked multiple questions related to payload communications in the context of space launch operations. For example, the Commission sought comment on whether payload operations, currently addressed through experimental licensing, should be addressed in part 25 of the Commission's rules. Because these newer commercial operations were not considered when many of its rules were first adopted, the Commission sought comment on any modifications to the current part 25 rules (
                    <E T="03">e.g.,</E>
                     default rules, bond requirements, fees, etc.) that may facilitate licensing and whether a streamlined process along the lines of the recently adopted process for small satellites would be appropriate for such operations. The Commission also asked if there are other licensing models that can be better suited for the needs of these payload operations. In response many commenters in this proceeding raised issues related to space operations such as on-orbit servicing (OOS), rendezvous, proximity space operations (RPO), Earth-escape operations, and lunar orbit missions, to name a few. Several of the leading industry operators for these types of activities, while urging the Commission to develop rules to better account for such space activities, suggested that these issues should be considered in a further notice of proposed rulemaking.
                </P>
                <P>
                    The Commission notes that many of the same operators that have commented on the need for spectrum allocation and licensing procedures for novel payload activities in this proceeding have also responded to the Commission's Notice of Inquiry on 
                    <PRTPAGE P="63300"/>
                    ISAM in the ISAM proceeding. ISAM refers to a set of capabilities that are used on-orbit, in transit, or on the surface of space bodies. Within the category of ISAM, “servicing” includes activities such as use of one spacecraft to inspect another, to dock with other spacecraft and provide support such as maintaining the station in its orbital location in order to extend the period of operations, or to repair or modify a spacecraft after its initial launch. These activities typically include the process of maneuvering close to and operating in the near vicinity of the “client” spacecraft, a set of activities often referred to as rendezvous and proximity operations (RPO). “Servicing” also involves transport of a spacecraft from one orbit to another and debris collection and removal. While the Commission acknowledges that this industry is advancing rapidly, it recognizes the importance and benefit of in-space services that could extend the life of satellites, reduce orbital debris, and more. The Commission agrees with commenters that it should not attempt to shoehorn these activities into a space launch licensing regime, nor is it necessarily appropriate to attempt to fit these operations into rules “designed for a previous space age.” Accordingly, the Commission will continue to expand the record on these in-space operations through its ISAM proceeding and welcomes continued comment and dialogue from the regulated community as the Commission seeks to develop short and long-term regulatory procedures for these operations.
                </P>
                <HD SOURCE="HD1">Scope of Service</HD>
                <P>
                    In the 
                    <E T="03">FNPRM,</E>
                     the Commission sought comment on how to define certain key terms for purposes of licensing commercial space launch operations, including “space launch operations,” “space launch vehicle,” and “reentry vehicle.” The Commission also sought comment on an appropriate scope for the commercial use of the 2200-2290 MHz and 2025-2110 MHz bands.
                </P>
                <P>
                    <E T="03">Space Launch-related Definitions.</E>
                     In requesting comment on how to define non-Federal “space launch operations,” the 
                    <E T="03">FNPRM</E>
                     noted that the STAs that have previously been granted have included telemetry from the launch vehicle and the payload, during the initial space launch, recovery of the booster, and the orbital and re-entry phases for operations such as cargo and crew delivery to and from the ISS. The Commission asked whether it would serve the public interest to include all of these operations in the definition of “space launch operations,” and whether there is a need to either limit the definition or further expand the definition to other space operations. Commenters are divided on whether “space launch operations” should encompass payload and expanded in-orbit operations, such as rendezvous and proximity operations, ISS docking, and space-to-space links.
                </P>
                <P>
                    While the Commission seeks to implement rules that will provide greater certainty and streamline access and use of the 2200-2290 MHz and 2025-2110 MHz bands, the Commission also remains cognizant that the two bands are already heavily encumbered and that there is a need to proceed cautiously regarding access to the bands for activities that go beyond the operations of a launch vehicle. Accordingly, the Commission finds that it is appropriate at this juncture to limit the definition of commercial space launch operations to activities associated only with the launch and recovery or reentry of a launch vehicle, and exclude payload and other on-orbit communications. The Commission concludes that the inclusion of payload and on-orbit operations, such as rendezvous and proximity operations, ISS docking, and space-to-space links, are outside of what can fairly be considered “space launch operations.” The Commission agrees with Boeing that such ancillary operations are outside the scope of the launch operations addressed in the 
                    <E T="03">FNPRM.</E>
                     The Commission therefore declines to extend the concept of commercial space launch beyond the operations of a launch vehicle itself. Because it is not clear from the record that the bands at issue can support streamlined authorization and access for payload and on-orbit operations today, the Commission is seeking further comment on these issues in the 
                    <E T="03">Second FNPRM</E>
                     (89 FR 6488, February 1, 2024) and through the Commission's ISAM proceeding, noted above.
                </P>
                <P>Instead, the Commission finds it appropriate to adopt a definition of “space launch operations” that is specific to launch vehicle operations. The Commission defines non-Federal “space launch operations” as any activity that places a launch vehicle, whether an expendable launch vehicle or a reusable launch vehicle or a reentry vehicle used for launch, and any payload or human being from Earth in a suborbital trajectory in Earth orbit, or otherwise in outer space, including pre-launch testing and recovery or reentry of the launch vehicle. The Commission finds it appropriate to broadly define “space launch operations” instead of including in the definition an exhaustive list of permissible operations or defining a launch by stages given that operations may vary from launch to launch. This definition is similar to the broad definition that the Commercial Space Launch Act, as amended, and the Federal Aviation Administration's (FAA) commercial space transportation rules apply to “launch.”</P>
                <P>
                    In the 
                    <E T="03">FNPRM,</E>
                     the Commission sought comment on whether and how to define “launch vehicle” for space launch operations purposes. SpaceX and TechFreedom advocate for the Commission to make use of its existing part 2 definition of “spacecraft.” NASA disagrees, arguing that a launch vehicle does not constitute a spacecraft, making the Commission's part 2 definition inapplicable.
                </P>
                <P>The Commission agrees with NASA that the term “spacecraft” is not appropriate. The term would not cover certain launch operations, such as first stages that do not go beyond the major portion of Earth's atmosphere or suborbital launches, but yet would encompass other activities, such as on-orbit missions, that the Commission is not including as part of a launch operation at this juncture. Instead, in line with the Commission's definition of “space launch operations,” it defines “launch vehicle” more specifically as a vehicle built to place a payload or human beings from Earth in a suborbital trajectory, in Earth orbit, or otherwise in outer space.</P>
                <P>
                    In seeking comment regarding the appropriate definition for “launch vehicle,” the 
                    <E T="03">FNPRM</E>
                     asked whether the Commission should draw on the definitions of “expendable launch vehicle” and “reusable launch vehicle” under part 87, and also sought comment on whether there should be any distinction between a “launch vehicle” and a “reentry vehicle” for space launch purposes. Few commenters addressed these issues. SpaceX and Relativity urge the Commission to avoid drawing distinctions that may become technologically outdated, while NASA states that the existing part 87 definitions for “expendable launch vehicle” and “reusable launch vehicle” are appropriate. As implied in the Commission's definition for “space launch operations,” it finds that a launch vehicle could be an “expendable launch vehicle,” a “reusable launch vehicle,” or a “reentry vehicle” used for launch. Accordingly, it is necessary for the Commission to define those terms. While § 87.5 of the Commission's rules provides definitions for “expendable launch vehicle” and “reusable launch vehicle” in the context of launches administered under part 87, these 
                    <PRTPAGE P="63301"/>
                    definitions describe such launch vehicles as “booster rockets.” Because the part 87 definitions may not adequately capture the launch vehicles that are in use today (or in the future), the Commission instead finds it appropriate to adapt definitions for launch vehicles using definitions from the FAA's commercial space transportation rules. The Commission defines “expendable launch vehicle” as a launch vehicle whose propulsive stages are used only once, and “reusable launch vehicle” as a launch vehicle that is designed to return to Earth substantially intact and may be launched more than one time or that contains vehicle stages that may be recovered by a launch operator for future use. Because it is feasible for commercial operators to conduct operations with a vehicle that cannot be solely described as a reusable launch vehicle (for example, the vehicle has the ability to be used for purposes other than launch), the Commission finds it appropriate to also include “reentry vehicle” and to adopt a definition similar to the FAA's definition of “reentry vehicle” as a vehicle designed to return from Earth orbit or outer space to Earth substantially intact. The Commission notes that because “reentry vehicle” under this definition could be applicable to either a launch vehicle or spacecraft designed to be capable of reentry, the Commission specifies that a reentry vehicle is regarded as a launch vehicle in the context of a space launch operation only to the extent that it is being used for launch purposes.
                </P>
                <P>
                    <E T="03">Permissible operations.</E>
                     In the 
                    <E T="03">FNPRM,</E>
                     the Commission noted that the 
                    <E T="03">Report and Order</E>
                     limited non-Federal use in the 2200-2290 MHz band to telemetry and tracking operations of launch vehicles during pre-launch testing and launch operations. Because the 2200-2290 MHz allocation was originally limited to the 2208.5-2213.5 MHz, 2212.5-2217.5 MHz, 2270-2275 MHz, and 2285-2290 MHz sub-bands, the 
                    <E T="03">FNPRM</E>
                     sought comment on whether the Commission should remove any presumptive limitation to the four sub-bands in the service rules to the extent that the Commission permits use beyond the original four sub-bands. Further, the 
                    <E T="03">FNPRM</E>
                     also proposed to restrict the commercial launch use of the 2025-2110 MHz band to telecommand uplink transmissions from the ground controller stations to the space launch vehicle. Noting the heavy usage of this band by BAS, CARS, and LTTS operations, as well as by Federal entities for space operations, Earth exploration satellite, space research, fixed, and mobile uses, the 
                    <E T="03">FNPRM</E>
                     asked whether it is feasible to accommodate uses in addition to the space launch telecommand uses.
                </P>
                <P>The Commission will clarify in its service rules that the use of the entire 2200-2290 MHz band is permissible for all launch vehicle-to-ground communications associated with telemetry and tracking operations, and the 2025-2110 MHz band is available for all ground-to-launch vehicle telecommand uses necessary to support space launch operations. As discussed above in section III.A., the Commission is revising Footnote US96 to enable use of the entire 2200-2290 MHz band. Accordingly, the Commission finds that it is necessary to also make clear in its service rules, in addition to the changes made to Footnote US96, that space launch telemetry activities are permitted throughout the band.</P>
                <P>Further, given that the 2025-2110 MHz band is heavily used, the Commission finds it necessary to limit the band to telecommand operations. Given the increasingly heavy use of the 2025-2110 MHz band and the importance in ensuring that incumbent operations are adequately protected, the Commission finds that it should not expand space launch uses beyond telecommand for this band.</P>
                <P>Permissible uses for the 2200-2290 MHz and 2025-2110 MHz bands, therefore, will be limited to telemetry, tracking, and command activities for space launch operations. Telemetry, tracking, and command necessary to support space launch operations may include, but are not limited to: (1) pre-launch testing, such as pre-flight checks, ground testing, and telemetry; (2) vehicle tracking, including the transmission of parameter data from a launch vehicle to ground; (3) telecommand signals for propulsive maneuvering of a launch vehicle and separation of payload from launch vehicle; and (4) telecommand signals for propulsive maneuvering of a reentry vehicle for return and recovery.</P>
                <P>The Commission emphasizes that these telemetry, tracking, and command communications are authorized only during space launch operations as defined above. This includes preparation for launch, launch of the launch vehicle, the launch vehicle's flight path, release of payload, and recovery or reentry of the launch vehicle. On-orbit communications after a launch vehicle separates from its payload are outside the scope of the service the Commission adopts today. The Commission recognizes that there may be circumstances where telemetry, tracking, or command activities may be necessary for the incidental orbital period of a launch vehicle before or after it has separated from its payload. The Commission will allow such incidental use only to the extent necessary to successfully complete a launch operation. However, incidental use must be limited only to the extent necessary, and communications on these frequencies that are not related to space launch operations as defined are not permitted.</P>
                <P>
                    <E T="03">Launch Vehicle-Satellite Communications.</E>
                     In the 
                    <E T="03">FNPRM,</E>
                     the Commission sought comment on the possibility of authorizing communications between space launch vehicles and satellite systems used for data relay, noting that radios designed as earth stations for communications with the Globalstar or Iridium satellite systems have been used on space launch vehicles in order to utilize those systems for data relay, including for telemetry, tracking, and command (TT&amp;C) purposes. Given this, the Commission asked whether these types of operations should continue to be licensed on an experimental basis. In response to these questions, Globalstar asserted that authorization for these types of operations in the L-band at 1610-1626 MHz should continue on an experimental basis only, given the limited number of launch vehicle customers and limited nature of the message traffic. Several other commenters generally voiced support for allowing such operations, while others noted concerns. The Commission agrees with Globalstar that currently the experimental licensing process serves as an adequate mechanism for licensing these types of communications. As Globalstar points out, current demand for these operations is limited.
                </P>
                <HD SOURCE="HD1">Eligibility</HD>
                <P>
                    In the 
                    <E T="03">FNPRM,</E>
                     the Commission sought comment about the appropriate eligibility criteria for holding commercial space launch licenses. The Commission proposed to use the supplemental eligibility criteria for part 87 flight test stations as a model for eligibility criteria.
                </P>
                <P>
                    After reviewing the record, the Commission adopts a modified version of the part 87 model and 
                    <E T="03">FNPRM</E>
                     proposal. Specifically, in order to be eligible to hold a commercial space launch license, an applicant must qualify as one of the following: a non-Federal entity that conducts space launch operations, or a parent of such entity or a subsidiary of such entity if either conducts space launch operations. Commenters expressed unanimous support for providing 
                    <PRTPAGE P="63302"/>
                    eligibility for commercial space launch licenses to those individuals and entities that conduct space launch operations.
                </P>
                <P>
                    The Commission declines to extend eligibility at this time to educational institutions and persons engaged in the design, development, modification, and flight test evaluation of a launch or reentry vehicle or launch or reentry vehicle components, as proposed in the 
                    <E T="03">FNPRM.</E>
                </P>
                <P>Commenters expressed concerns over extending eligibility in this fashion, arguing, for example, that such operations would be difficult to monitor and control. Given the congested nature of the bands at issue, the Commission opts to limit eligibility for permanent authorization at this time to only those entities that conduct commercial space launch operations, as recommended by NTIA/NASA. The Commission may revisit its eligibility criteria in the future, if needed.</P>
                <P>The Commission also declines to require commercial space launch license applicants to include a separate certification with their application to establish eligibility. As Boeing observed, license applicants using Form 601 already must certify as to their eligibility to hold the license for which they are applying. General Certification Statement 7 on Form 601 requires the applicant certify that “it has reviewed the appropriate Commission Rules defining eligibility to hold the requested license(s), and is eligible to hold the requested license(s).” The Commission concludes that requiring a separate eligibility certification would be a superfluous requirement for license applicants.</P>
                <HD SOURCE="HD1">Shared Frequency Use and Cooperative Use of Facilities</HD>
                <P>
                    Consistent with the Commission's decision to allocate the 2025-2110 MHz band for commercial space launch operations on a secondary basis and modify the allocation of the 2200-2290 MHz band, the Commission adopts its proposal to provide non-Federal space launch operators access to both bands on a shared, non-exclusive basis. The Commission understands that these allocations will be used by space launch operators to conduct telemetry, tracking, and command operations of launch vehicles during pre-launch testing and space launch operations and that they will more than often be working with the same launch site operators given the finite number of suitable launch sites. As the Commission noted in the 
                    <E T="03">FNPRM,</E>
                     given the potential for many different launch vehicle operators to use a given launch facility, authorizing commercial space operations on a shared and cooperative basis appears to be a reasonable approach for providing spectrum access to multiple space launch entities. The Commission finds therefore that providing access on a shared, non-exclusive basis will offer the burgeoning commercial space launch industry a more predictable, collaborative, and flexible means of gaining access to spectrum, one that will provide greater regulatory certainty and foster continued growth in this sector. The Commission's decision is supported by the record in this proceeding as the majority of commenters filed in support of spectrum sharing on a non-exclusive basis through the use of coordination techniques.
                </P>
                <P>
                    The Commission received few responses to the question raised in the 
                    <E T="03">FNRPM</E>
                     regarding whether it should adopt a non-discrimination policy for all space launch operations similar to the rule imposed by the part 87 rules on access to flight test facilities and none of these commenters support imposing such a requirement. The Commission agrees with Boeing that the cooperative use of space launch facilities are more appropriately addressed through the use of private contractual arrangements and will not impose a non-discrimination policy in this context. Moreover, because the Commission grants licenses on a shared, non-exclusive basis at a nationwide level, the Commission will not be issuing only a single site-based authorization per launch site, which, as SpaceX points out, obviates the need for the Commission to adopt a non-discrimination requirement because launch vehicle operators will have other sites around the country to choose from.
                </P>
                <HD SOURCE="HD1">Licensing</HD>
                <P>
                    In the 
                    <E T="03">FNPRM,</E>
                     the Commission indicated that its goals in licensing space launch operations are two-fold: (1) to encourage innovations and investments in the U.S. space commerce; and (2) to ensure a regulatory environment conducive to the establishment of a competitive U.S. commercial space launch sector while protecting Federal and other users in the bands. To meet these goals and to facilitate the shared spectrum access approach discussed above, the Commission will issue space launch licenses on a nationwide, non-exclusive basis.
                </P>
                <P>The Commission sought comment on various licensing models with the aim of providing regulatory certainty in the marketplace while minimizing administrative burdens and duplicative regulations. Specifically, the Commission asked commenters whether it should consider applying a site-based licensing model in a shared use situation as fixed, well-defined areas of operation can simplify coordination during the application process for services requiring frequency coordination, and facilitate intensive spectrum sharing. The Commission also suggested that a site-based approach would enable stakeholders to identify quickly licensees in the band and their specific areas of operation in the event interference issues arise thus allowing parties to resolve such issues in the shortest timeframe practicable.</P>
                <P>
                    The Commission also sought comment on other licensing models that may be suitable in the space launch operations context. Among other things, the Commission asked whether it should consider a new approach combining various aspects of space-based services and aeronautical service licensing rules or whether it would be appropriate to license space launch vehicles similar to space stations and their communicating ground/earth stations on a single or multiple site basis. In addition to inquiring about conditioning ground/earth station operations on the filing of a certification that any required frequency coordination has been satisfactorily completed prior to a space launch, the Commission asked whether it could license space launch operations in a manner similar to previous licensing models applicable to certain wireless services such as the 3650-3700 MHz band. In doing so, the Commission sought to provide space launch operators access to various spectrum bands on a non-exclusive, yet protected, basis, subject to measures designed to promote shared use of spectrum, such as a registration and frequency coordination requirement prior to each launch. The 
                    <E T="03">FNRPM</E>
                     also considered ways to reduce potential administrative burdens and streamline the information that would be needed for initial licensing and then registration and coordination prior to a planned launch.
                </P>
                <P>
                    As discussed above, the Commission finds that space launch access to spectrum on a shared basis is appropriate and finds that permitting such access on a nationwide basis similar to the licensing mechanism established for the 3650-3700 MHz band is also warranted. There is wide support in the record for licensing commercial space launch operations on a nationwide, non-exclusive basis covering related launch vehicles across multiple launch sites. The Commission finds that such an approach will give certainty to licensees and provide the efficiencies of scale and scope that will 
                    <PRTPAGE P="63303"/>
                    spur innovation, investment, and rapid deployment of space launch services.
                </P>
                <P>The Commission also agrees with commenters who assert that a licensing framework based on nationwide, non-exclusive licenses offers a number of distinct advantages over a site-based licensing regime. In short, the record shows that a single nationwide, non-exclusive license offers greater administrative and regulatory efficiencies than either a site-based licensing regime or the arduous STA process, particularly as the volume of commercial space launch activities continues to grow.</P>
                <P>Nationwide licensing offers the advantages of a simpler, more streamlined application process that shifts the burden of information collection from the licensing stage to post-licensing site registration and per-launch coordination with the relevant Federal and non-Federal entities. Moreover, nationwide, non-exclusive licensing offers space launch operators the benefit of only having to file a single license to cover a range of different launch sites shared by multiple co-frequency operators, a far more straightforward process than the site-by-site STA process. The Commission agrees with SpaceX that granting a series of authorizations by site, frequency band, and mission phase would create unnecessary burdens and that structuring the license in a comprehensive way enables each launch provider to have a “single, all-in-one authorization” to cover all of its activities thereby obviating the need for multiple licenses to cover different launch sites, different recovery sites, and different launch vehicles.</P>
                <P>From an operational standpoint, nationwide licensing offers space launch operators the flexibility to accommodate future expansion in the space launch industry as more launch sites (Federal or non-Federal) are constructed, new and improved launch vehicle technologies are introduced, and the number of licensees operating in the bands continues to grow. As ULA notes, nationwide licensing affords space launch operators the operational flexibility to launch from any U.S. launch site to account for the multitude of variables, including weather delays, payload changes, orbital-path and/or destination shifts, and other “uncontrollable” factors that can affect the location and timing of launches. Such flexibility is critical as launch vehicle operators are not always the same entity as the launch site operator, with variability from launch-to-launch in terms of the entities involved on any given launch on any given date and time.</P>
                <P>
                    Prospectively, nationwide, non-exclusive licensing also could provide the Commission with a strong foundation to build upon as it develops a regulatory scheme that will accommodate space-to-space communications through the record being developed by the 
                    <E T="03">Second FNPRM.</E>
                     With the input of Federal and non-Federal stakeholders, the Commission anticipates that it will develop a record to determine the best path forward for licensing on-orbit services, including RPO and OOS. As discussed in further details below, the Commission would pair a nationwide licensing scheme with post-licensing coordination to ensure cooperation with and avoid harmful interference to co-frequency entities. Post-licensing coordination under this framework would permit non-Federal licensees who are sharing the frequency bands to address specific areas of operation associated with each specific launch (launch site location and corresponding stations, launch vehicle, in-flight trajectories or coordinates, etc.) in a manner similar to existing coordination processes.
                </P>
                <P>
                    The Commission concludes that the 3650-3700 MHz licensing framework that authorized nationwide, non-exclusive licenses for terrestrial operations on a cooperative shared basis offers a suitable template to license commercial space launch operations in a similar streamlined fashion. The Commission bases this conclusion on the unique nature of the service, including the variability of launches. The Commission agrees with the Satellite Industry Association (SIA) that a modified version of the 3650-3700 MHz licensing model would provide a good licensing framework for space launch operators to obtain nationwide, non-exclusive licenses for shared spectrum use. The Commission also agrees with ULA that it should apply elements of the 3650-3700 MHz licensing framework, including the requirement that operators can obtain a nationwide license only if they agree to cooperate with and avoid harmful interference to co-frequency licensees and cannot commence operations until they register the sites affiliated with their launch service. In the 3650-3700 MHz proceeding, the Commission indicated that nationwide, non-exclusive licenses would serve as a prerequisite for registering individual fixed and base stations, 
                    <E T="03">i.e.,</E>
                     a licensee cannot operate a fixed or base station before registering it under its license and must delete registrations for unused fixed or base stations to facilitate proper coordination.
                </P>
                <P>Like the 3650-3700 MHz licensing regime, any space launch operator interested in obtaining a nationwide, non-exclusive license can do so on the condition that they agree to cooperate with and avoid harmful interference to co-frequency entities and complete coordination efforts to avoid in-band interference, including providing the information necessary to conduct coordination via site registration. All commercial space launch licensees in the band will have equal rights to the use of the spectrum as long as they comply with all applicable licensing, service, and operating rules but all the licensees will have a mutual obligation to cooperate and avoid causing harmful interference to other users in the band. Applicant qualification for non-exclusive nationwide wireless licenses in the space launch service will be assessed in accordance with FCC Form 601 and Commission rules. There will be no limit to the number of non-exclusive nationwide wireless licenses that may be granted for the spectrum allocated to commercial space launch services, and these licenses will serve as a prerequisite for registering launch sites and operational parameters, space launch vehicle stations, individual ground/earth stations, and itinerant stations needed to support a launch. The Commission notes that the registration process will be streamlined to the extent possible and will be done electronically through the Universal Licensing System (ULS) as suggested by several commenters. The initial filing date for these commercial space launch licenses, along with directions on how to use the ULS, will be announced in a future Wireless Telecommunications Bureau (WTB) Public Notice. The Commission notes that in order to keep the ULS licensing and registration database for space launch services accurate and up-to-date, the Commission delegates to the WTB the authority to adopt rules regarding the reporting of database information including reporting of any license or secondary markets transactions. WTB will issue a Public Notice seeking comment on these issues, as appropriate.</P>
                <P>
                    As stated above, the Commission is hereby creating a new rule part 26 that will set forth the licensing, operation, and service rules for the space launch service. With respect to their regulatory status under the Communications Act, space launch service licensees operating in these shared use bands will be providing services on a non-common carrier basis after they obtain their 
                    <PRTPAGE P="63304"/>
                    licenses and register the launch site and corresponding fixed, base, and itinerant stations as well as mobile stations associated with the launch vehicle to comply with post-license grant coordination requirements. Consistent with the non-exclusive nature of the licensing scheme the Commission is adopting here, it will not impose any spectrum aggregation limits, either in-band or out-of-band, or eligibility restrictions other than the eligibility criteria discussed above and statutory foreign ownership restrictions. All potential space launch service providers will have equal access to these bands and by opening this spectrum to as wide a range of eligible applicants as possible, the Commission aims to encourage new entry and investment as well as entrepreneurial efforts to develop new launch-related technologies and services, while helping to ensure efficient spectrum use. The Commission further believes that this approach will promote economic opportunity and competition in the subject bands. The Commission will not impose a performance or build-out requirement because space launch sites and launch vehicles may vary from launch to launch, making specific construction requirements impractical. Of course, any interested party is free to, depending on the site, construct facilities and may operate according to its particular business plan at any time, as long as it has a valid wireless license, registers its stations, and complies with coordination requirements as well as other applicable rules. However, the Commission strongly expects space launch service providers to consult with NTIA in advance of commencing construction on a new launch site. The Commission concludes such a consultation is in the provider's best interest, as providers will have the information needed from NTIA to make an informed decision about whether to proceed with construction at a given site. Although the Commission does not impose a performance requirement, it will require that space launch licensees delete registrations for unused sites and unused fixed, base, itinerant, and mobile stations in order to maintain ULS database integrity and facilitate efficient coordination between licensees.
                </P>
                <P>
                    Any eligible party may apply at any time for a license in these frequency bands regardless of the presence of other licensees in the geographic area where it intends to use the spectrum and licensees may assign or transfer their non-exclusive nationwide authorizations, upon application to and prior approval from the Commission. However, the Commission's decision to license the space launch services on a non-exclusive nationwide basis obviates the need to adopt partitioning and disaggregation provisions because partitioning and disaggregation is only pertinent in geographic licensing settings where the licensee has 
                    <E T="03">exclusive</E>
                     use of a particular area. For similar reasons, the Commission need not make its spectrum leasing rules applicable to licensees because the non-exclusive licensing scheme the Commission employs here, coupled with the required post-license coordination, permits a high degree of access and spectrum re-use in these bands by multiple users, while minimizing the likelihood of harmful interference. Accordingly, the spectrum leasing arrangements described in the 
                    <E T="03">Secondary Markets Report and Order</E>
                     (68 FR 66252, November 25, 2003) are not applicable, and the Commission does not see a need to apply those spectrum leasing rules and policies to this spectrum at this time.
                </P>
                <HD SOURCE="HD1">Authorized Bandwidth</HD>
                <P>
                    In the 
                    <E T="03">FNPRM,</E>
                     the Commission proposed to grant licenses for commercial space launch operations using a 5 megahertz bandwidth for the 2200-2290 MHz band and sought comment on the appropriate bandwidth for the 2025-2110 MHz band. The Commission also sought comment on whether to permit licensees to use larger bandwidths upon adequate justification, and also on whether to authorize operations using a range of bandwidths instead of a fixed bandwidth of 5 megahertz. After reviewing the record, as well as the space launch operations the Commission has licensed on experimental bases to date, the Commission will issue licenses of any bandwidth a licensee chooses, up to 5 megahertz, for both bands. In the event a licensee requires a bandwidth greater than 5 megahertz, the Commission will authorize a bandwidth exceeding 5 megahertz upon adequate justification for why such bandwidth is necessary for space launch operations in a particular launch. For purposes of such requests, licensees must demonstrate that the bandwidth requested is that which is necessary to accomplish the specific telemetry, tracking, or command operation(s) at issue. This framework is similar to the Commission's licensing of the 2360-2395 MHz band space launch telemetry and telecommand operations, which are licensed on a range of bandwidths capped at 5 megahertz, with larger bandwidths available on a case-by-case basis.
                </P>
                <P>Given that the majority of requests for experimental licenses for the 2200-2290 MHz band to date have requested bandwidths smaller than 5 megahertz, the Commission finds it appropriate to impose a 5 megahertz maximum bandwidth limitation. In light of the existing usage of this band, the Commission finds it appropriate to limit the authorized bandwidth to only that which is generally necessary for a launch. The Commission notes that the limit for Federal space launches using the 2200-2290 megahertz band is 5 megahertz, and NASA supports applying a 5 megahertz maximum bandwidth to non-Federal launch operations as well. While there was limited discussion in the record regarding the appropriate bandwidth limit for the 2025-2110 MHz band, NOAA notes that Federal entities are limited to a maximum bandwidth of 5 megahertz in both the 2025-2110 MHz and 2200-2290 MHz bands in order to reduce congestion and to ensure compatibility with existing operations. The Commission concludes that it would be appropriate to apply a 5 megahertz limit to non-Federal uses of the 2025-2110 MHz band for these reasons as well. While some industry commenters advocated for an authorized bandwidth exceeding 5 megahertz, the Commission finds that a 5 megahertz limit for both the 2025-2110 MHz band and the 2200-2290 MHz band will help to lessen impacts to other users in these bands, and put commercial space launch operators on par with Federal entities as well as those using the 2360-2395 MHz band for launch operations. And as explained below, the Commission is allowing licensees to exceed the 5 megahertz bandwidth to the extent they can demonstrate such additional bandwidth is necessary for a given launch.</P>
                <P>Further, the Commission finds that allowing licensees to choose their own bandwidth, up to 5 megahertz, will provide licensees with the flexibility to undertake a variety of commercial space launch activities, including future industry developments. No commenters opposed this approach, while NASA supports allowing non-Federal users to use any bandwidth up to and including 5 megahertz, noting that the narrower emissions will be easier to coordinate with existing Federal users. For those reasons, the Commission will allow licensees to choose a bandwidth of any size, up to 5 megahertz.</P>
                <P>
                    While the Commission finds that it should impose a maximum bandwidth of 5 megahertz as a means to help lessen the impact of commercial space launch operations on these bands, the 
                    <PRTPAGE P="63305"/>
                    Commission is aware that there may be instances when wider bandwidths may be necessary for a given launch. The Commission therefore finds it appropriate to permit commercial space launch operators to use bandwidths exceeding 5 megahertz on a case-by-case basis. Several commenters advocate for bandwidths exceeding 5 megahertz. Conversely, NASA argues that authorized bandwidth should be capped at 5 megahertz, arguing that the same restriction applies to Federal users in the 2200-2290 MHz range. However, bandwidths exceeding 5 megahertz in the 2200-2290 MHz band are available to Federal users upon adequate justification. In addition, commercial launches in the 2200-2290 MHz range using bandwidths exceeding 5 megahertz have been successfully coordinated with NTIA in the past. Similarly, as noted, although launch operations in the 2360-2395 MHz band have a limit of 5 megahertz, the Commission's rules permit applicants to seek authorization for wider bandwidths.
                </P>
                <P>Accordingly, for those commercial space launch operators seeking authorizations for bandwidths exceeding 5 megahertz in the 2200-2290 MHz and 2025-2100 MHz bands, the Commission will apply the NTIA framework for such requests. Specifically, the requesting space launch operator shall submit a justification as part of the registration process for a launch on why the requested bandwidth is necessary for the specific TT&amp;C space launch operation, including an explanation of why the operator's requirements cannot be satisfied using a bandwidth of 5 megahertz or less. The applicant's justification will be carefully assessed to determine whether a request for bandwidth in excess of 5 megahertz for a given launch will be granted. Such requests will not be routinely granted given the goal of limiting impacts to other users in the band. As discussed below, all launch operations must be coordinated; the Commission notes that, given the heavy usage of these bands, it may be difficult to successfully coordinate operations involving requests for bandwidths greater than 5 megahertz.</P>
                <HD SOURCE="HD1">License Term and Renewal</HD>
                <P>
                    The Commission adopts a ten-year license term for commercial space launch operations. In the 
                    <E T="03">FNPRM,</E>
                     the Commission tentatively concluded that a ten-year term would provide sufficient certainty and flexibility for space launch providers. The Commission has applied ten-year license terms to similar services, such as part 87 aviation, part 90 radiolocation, and part 90 telemetry and remote control operations. More generally, ten-year license terms are common among the Commission's various wireless services.
                </P>
                <P>Several commenters support the Commission's ten-year term proposal while others advocate for a 15-year license term. The Commission does not agree that a longer 15-year term is necessary for commercial space launch operations. Regarding space stations and earth stations, the operation of satellite communications under part 25 presents a distinct set of factors from space launch considerations, including the scope and extent of deployment. Although the Commission has also adopted 15-year license terms under certain circumstances for non-satellite wireless services, it has done so to address circumstances not present here, such as the complexities surrounding 5G deployment, relocation and repacking of incumbent operations, and support for network expansion and densification. The Commission instead agrees with SIA that a ten-year term is sufficient to provide launch operators with the certainty of a longer license term, and will encourage launch operators to make long-term investments. And while the Commission seeks to provide commercial space launch operators with as much certainty as possible, the Commission also finds it necessary to set timeframes that will enable us to adequately verify that licensees are operating within their authorized parameters. Given the congested nature of the bands at issue, the Commission conclude that such review should take place after ten years, not 15.</P>
                <P>
                    Given the heavy use of these bands, the Commission also finds it appropriate to require space launch operators to demonstrate that they qualify for license renewal. In 2017, the Commission harmonized the renewal processes for numerous Wireless Radio Services (WRS). The Commission determined that a site-based WRS licensee would meet the Commission's renewal standard if it could certify that it is continuing to operate consistent with its most recently filed construction notification (or most recent authorization, when no construction notification is required), and make certifications regarding permanent discontinuance and substantial compliance with Commission rules and policies. The Commission also provided that, for geographic-based licenses to qualify for renewal at the end of an initial license term, the licensee must show that it timely constructed to any level(s) required by the service-specific rules for either provision of service to the public or for the licensee's private and internal needs, and, thereafter, consistent with the Commission's permanent discontinuance rules, continuously provided service or operated at or above the required level(s) for the remainder of the license term. The 
                    <E T="03">WRS Order</E>
                     (82 FR 41530, September 1, 2017) does not apply to Wireless Radio Services that are licensed by rule or on a “personal” basis or that have no construction/performance obligation.
                </P>
                <P>Because launch operations are dissimilar to most other wireless services, the Commission does not find it appropriate to apply to commercial space launch licensees the same renewal standards that are applied to geographic-based or site-based WRS licensees. Instead, a commercial space launch licensee will be entitled to renewal if it remains otherwise qualified and can certify that (1) it has operated and is continuing to operate consistent with Commission rules and the terms of its existing authorization, and (2) it has complied with the required coordination throughout its license term. Given the nature of space launch operations (for example, there may be significant periods of time between launches), the Commission will not apply discontinuance of operations rules.</P>
                <P>
                    Most of those commenting on this issue support a presumptive renewal expectancy and oppose renewal showings. Commenters that oppose the use of a renewal showing claim that one is not necessary given the non-exclusive nature of the band, which, commenters claim, prevents spectrum warehousing by itself. While the Commission agrees that a non-exclusive band presents different considerations from an exclusive licensing regime, the Commission concludes that imposing this requirement will aid us in verifying that space launch entities are operating within licensed parameters, thereby helping to manage use and prevent interference within congested bands. As noted in the 
                    <E T="03">FNPRM,</E>
                     the Commission concludes that requiring a renewal showing from commercial space launch entities would facilitate efficient spectrum use by ensuring that licensees use the spectrum productively, collaboratively, and in compliance with Commission rules. For that reason, the Commission adopts the aforementioned renewal standard.
                </P>
                <HD SOURCE="HD1">Application Process</HD>
                <P>
                    The Commission concludes that it serves the public interest and the 
                    <PRTPAGE P="63306"/>
                    Commission's policy objectives to promote innovation and investment in the United States commercial space launch industry by assigning non-exclusive nationwide licenses for the space launch services which will not result in mutually exclusive applications and therefore will not be subject to the competitive bidding requirements of section 309(j) of the Communications Act. Consistent with the Commission's decision to adopt a non-exclusive nationwide licensing scheme, the Commission will adopt an application process modeled after the 3650-3700 MHz licensing framework to permit space launch operators access to various spectrum bands on a non-exclusive basis, subject to measures designed to promote shared use of spectrum, that will impose a post-license grant frequency coordination and registration requirement prior to each launch.
                </P>
                <P>
                    <E T="03">Application Form and Licensing Database.</E>
                     Building on the Commission's decision to utilize a modified version of the 3650-3700 MHz licensing model, it will require space launch operators to apply for and obtain a nationwide, non-exclusive license in ULS. Once licensed, space launch operators, working through a third-party coordinator, must coordinate each launch with NTIA and other non-Federal users, as discussed 
                    <E T="03">infra.</E>
                     After that per-launch, per-site coordination process has been successfully completed, space launch operators must then register in ULS the technical and operating parameters associated with the coordinated launches. Only after the final technical parameters of a given launch are registered under their license can space launch operators commence their launch service subject to the condition that they re-coordinate a launch if operational details change and agree to maintain and update those registered sites and stations, including deleting any unused or superseded launch site or station information to facilitate coordination. The information required for the application, coordination and registration processes will be identified in a Public Notice.
                </P>
                <P>A number of commenters weighed in on the use of a common database to receive applications for launch operators seeking authorization to provide commercial space launch services and to register terrestrial sites and associated stations. Several commenters advocated for the use of the Commission's existing licensing databases, Universal Licensing System (ULS) or International Communications Filing System (ICFS), and their associated forms and schedules. The Commission agrees with Boeing that requiring applicants to file FCC Form 601 and its associated schedules through the ULS would be expedient and administratively efficient and notes that the 3650-3700 MHz band upon which it is basing the Commission's licensing approach has been successfully administered through ULS. The Commission therefore declines to use Form 312 and Schedule S and ICFS at this time. While several commenters urged the Commission to consider using FCC Form 312 and Schedule S in the ICFS system in line with part 25 authorizations, the Commission agrees with Boeing that Form 312 and Schedule S would require significant revisions to accommodate space launch licenses, changes that would be difficult to implement with the older ICFS software. The Commission also finds using the ULS database to field applications is consistent with its decision to create a new rule part 26 for the space launch service rather than shoehorning a unique and fast developing service into existing rule parts like part 87, 90, or 25.</P>
                <P>
                    <E T="03">Filing requirements and station registration to facilitate post-licensing coordination with frequency coordinators and NTIA/DoD.</E>
                     The Commission received only a few comments regarding the information that applicants should provide in an application. The Commission finds that these comments have merit, but that technical data such as frequencies would be most useful for coordinating and registering specific launches. For purposes of applying for the nationwide, non-exclusive license, the Commission finds that it is only necessary for launch providers to provide administrative information and later register data associated with a specific launch operation, such as the name of the launch sites and their latitude, longitude, address, corresponding stations, and area of operation for mobile stations. Indeed, data such as frequencies and technical parameters will vary from launch to launch and are not necessary for assessing an application for a nationwide, non-exclusive license.
                </P>
                <P>The Commission will delegate to the WTB the authority to further review and refine the filing process. As stated previously, the initial filing date for these commercial space launch applications, along with directions on how to use the ULS, will be announced in a future WTB Public Notice. Correspondingly, the Commission also delegates to the WTB the authority to specify application information, to make any necessary modifications to the FCC Form 601 and its related schedules, including any reprogramming of the ULS software, to accommodate the application and post-license site and station registration and frequency coordination process prior to each launch. The WTB will issue a Public Notice, in consultation with the Space Bureau and Office of Engineering and Technology, seeking comment on these issues, as appropriate, to further refine the Commission's online application process and accommodate frequency coordination.</P>
                <P>
                    As discussed 
                    <E T="03">infra,</E>
                     the Commission will require space launch operators to coordinate every launch with applicable Federal and non-Federal entities. While the WTB after seeking comment will issue a Public Notice identifying information that will be required with respect to the application and coordination processes as well as post-license grant registrations, licensees will likely be expected to provide, at a minimum, the same operational and technical parameters currently required of applicants seeking special temporary authority for their space launches to facilitate post-licensing coordination. The Commission anticipates that licensees will identify requisite site and station information, including the specific coordinates of fixed, base, and itinerant stations (
                    <E T="03">e.g.,</E>
                     latitude and longitude), frequency channels, launch trajectories, launch window or planned launch date, and any other technical and operational information (
                    <E T="03">e.g.,</E>
                     antenna characteristics, power levels, emission designators, launch vehicle trajectory) needed by a third-party frequency coordinator to submit the launch coordination request to the relevant non-Federal and Federal entities. Other information could include coordinates and operational parameters of the earth/ground stations launch operators will be using to provide service at a particular launch site, including whether the sites are Federal or FAA-licensed commercial spaceports or non-Federal launch sites (
                    <E T="03">e.g.,</E>
                     Spaceport America in New Mexico and Mojave Air and Space Port in California). Operators may also be asked to provide any coordination agreements that they have already entered into with co-frequency entities or successfully completed coordination conducted by the designated frequency coordinator. As part of this post-license grant coordination process, launch providers must consistent with the Commission's service rules comply with the continuing obligation to update their licenses to ensure proper coordination. As noted, the WTB Public Notice will 
                    <PRTPAGE P="63307"/>
                    seek comment on collection of this coordination data as well.
                </P>
                <P>
                    <E T="03">Space Launch Vehicle Operations with Earth Stations Outside the United States.</E>
                     The Commission agrees with commenters that any launch vehicle operator that requires communication with a foreign earth station must obtain the necessary approvals for operations of the earth station from the appropriate regulatory body in that country. However, this does not mean that the launch vehicle can be correctly viewed as licensed by that same regulatory body. The Commission is unaware of any International Telecommunications Commission (ITU) Administration that views a U.S. launch vehicle upper stage as a station subject to its licensing (See Article 18.1) simply because it communicates with an earth station within its territory, and similarly this is not the approach taken for non-U.S. launch vehicles communicating with U.S. earth stations. More generally the Commission's current licensing of space stations, including under parts 5, 25, and 97, accounts for space station operations with earth stations outside the United States. The conditions that the Commission places on a satellite license continue to be in effect for the duration of satellite operations regardless of whether the satellite communicates with non-U.S. licensed earth stations, and in some circumstances the space station authorization may involve communications exclusively with earth stations outside the United States.
                </P>
                <P>
                    <E T="03">Operations Inside the United States with non-United States Space Launch Vehicles.</E>
                     The commission received limited comments on this issue. The Commission agrees with Boeing that there may not be a current demand for these types of communications. The Commission concludes that it can address any requests for these communications through the experimental licensing process for the time being. The Commission believes this approach addresses Astra Space's comments as well by providing an avenue for operators to seek authorization.
                </P>
                <P>
                    <E T="03">ITU Process.</E>
                     Commenters generally oppose requiring submissions to the ITU related to space launch operations. The Commission agrees with commenters that under current circumstances many U.S.-based space launches may not result in the realistic potential for international harmful interference, particularly with respect to the first stage of a launch vehicle or a single stage launch vehicle, for which radio operations may be limited to line-of-sight communications with ground stations in U.S. territory and occur while the launch vehicle is over oceanic areas. As such, engaging in a filing process with the ITU might be viewed as an unnecessary administrative hurdle, and any interference concerns can be addressed bilaterally with adjacent countries. However, the Commission also recognizes its duty to carry out the United States' treaty obligations as a ratifying member of the ITU convention, and that this includes an obligation to ensure that U.S.-licensed operations do not cause harmful interference on an international scale. This concern is of greater significance for launch vehicle upper stage operations involving earth stations outside the United States, as those operations do present the potential for interference in multiple countries. These competing considerations must be taken into account in determining whether ITU filings should either be uniformly required for licensed part 26 operations, or whether operators should be exempted from such requirements.
                </P>
                <P>A third option is to require applicants to submit appropriate draft documentation for submission to the ITU on a case-by-case basis, as is the current practice, if the scope and nature of the space launch operations would have the potential to cause harmful interference in another country. For example, the Commission may consider requiring a filing if the upper stages of a launch vehicle will be communicating with earth stations outside the United States. This would align the U.S. with the practice of other countries that submit materials to the ITU for upper stage orbital operations. The Commission concludes that this third option is preferrable. The Commission will not adopt a blanket requirement that all space launches require an ITU filing, yet it does not preclude its ability to require such a filing in the event the Commission deems that such a filing would be necessary and prudent in order to avoid harmful interference with other countries. The Commission has taken steps to create a flexible licensing regime for space launches under the new part 26, including allowing one launch license to cover multiple launches and nationwide launch locations, and a 10-year license duration. Particularly given the longer-term aspects of the licensing approach adopted, requiring an ITU submission as part of the license application process will not create an undue burden to operators in the event a filing is deemed necessary and appropriate. The Commission also notes that it will be bound by any future ITU requirements related to space launch filings and so its current position is subject to change upon the issuing of new ITU regulations in this area.</P>
                <HD SOURCE="HD1">Frequency Coordination</HD>
                <P>
                    In the 
                    <E T="03">FNPRM,</E>
                     the Commission sought comment on the appropriate coordination process between Federal and non-Federal entities to be used prior to the grant of an application for space launch frequencies as well as a coordination process for the ongoing use of these frequencies by operators during their license terms. The Commission also sought comment on whether it should require applicants for a license in space launch frequencies to undergo a pre-application coordination requirement similar to that specified in § 87.305, or whether, in the alternative, the Commission should impose a different coordination process.
                </P>
                <P>As a general matter, all of the commenters in the record support the use of frequency coordination and spectrum deconfliction to prevent harmful interference to co-frequency non-Federal/Federal operations and ensure the efficient use of spectrum in these bands. Where they differ is when the coordination process should take place. While a few commenters argue in favor of a pre-license grant coordination approach, most commenters favor a post-license grant coordination and spectrum deconfliction process. Comments submitted by Federal stakeholders emphasize the importance of coordinating on a case-by-case, launch-by-launch basis to ensure that Federal users in the bands are protected from harmful interference.</P>
                <P>
                    Based on the record in this proceeding, the Commission finds that post-license grant coordination will ensure cooperation with and avoid harmful interference to co-frequency entities, both Federal and non-Federal, operating in the 2025-2110 MHz and 2200-2290 MHz bands. The Commission believes that post-license grant coordination in concert with a comprehensive nationwide, non-exclusive licensing regime will provide space launch operators access to the spectrum they need and relief from the administrative burdens associated with either a site-based licensing approval process or the current launch-by-launch STA regime. Post-license grant coordination will also endow them with the operational flexibility to modify their launch parameters (
                    <E T="03">e.g.,</E>
                     frequency channels, antenna height, trajectory, power level) closer in time to the launch event and the latitude to adjust their services to accommodate demand as it arises.
                    <PRTPAGE P="63308"/>
                </P>
                <P>The Commission reaches this decision based on the length of the license term (10 years) and a record that demonstrates the complicated logistics surrounding space launch operations, including multi-factored variability of launch elements that are beyond the licensee's control, as well as changes in the operational environment on and around Federal ranges and other sites that are likely to occur over time. On balance, these factors suggest that a one-time pre-licensing coordination would be insufficient to protect co-frequency entities from harmful interference in spectrum bands that commenters suggest are already congested. Moreover, given the anticipated growth of space launch services, the Commission finds that a one-time pre-licensing coordination is unlikely to cover all the space launches that will occur over the life of an operator's license nor would it be able to anticipate the introduction of new launch sites, changes in launch vehicles, or technological innovations that are likely to occur during those ten years. For these reasons, the Commission believes that third-party coordination and spectrum deconfliction would be better executed post-license grant.</P>
                <P>Post-licensing coordination affords space launch operators who are sharing these frequency bands (and launch facilities) the opportunity and flexibility to adjust specific areas of operation (site location, launch vehicle, or in-flight trajectories, etc.) as they come up with each individual launch event, particularly as they get closer to the scheduled launch date. For space launch operators seeking launch clearance, it is critically important that their post-grant coordination requests cover the key elements of a launch so they can adequately complete the required per-launch coordination process. Consistent with the Commission's decision to adopt allocation and service rules for space launch services for two distinct bands, 2200-2290 MHz (space-to-earth) and 2025-2110 MHz (earth-to-space), the Commission will adopt a post-license grant coordination approach that takes into account the unique characteristics of these bands. The Commission will also approach coordination in a manner that reflects its decision to apply a modified 3650-3700 MHz licensing framework to grant space launch operators a nationwide, non-exclusive blanket license on the condition that they agree to cooperate with and avoid harmful interference to co-frequency entities and cannot operate launch sites and corresponding radio stations (earth/ground stations, stations on their launch vehicles, and any associated mobile stations on the ground) until they have first registered them under their license after completion of coordination through a third-party coordinator.</P>
                <P>The Commission finds significant efficiencies justifying the use of a third-party frequency coordinator in the bands at issue. Given the variety of non-Federal and Federal stakeholders sharing this spectrum, all with different operational and technical needs, and the administrative burdens licensees face in having to submit to different coordination processes, the Commission finds it prudent to designate a single entity that will serve as both a clearinghouse and as an intermediary in negotiating operational parameters with SBE, NTIA, government automated frequency coordination (AFCs), and co-frequency operators. Currently, space launch operators are tasked with determining the impact of their services on non-Federal and Federal users whose operations may or may not have already been coordinated by SBE to protect BAS, CARS, and LTTS in the 2025-2110 MHz band as well as the effect on co-frequency operators and Federal incumbents that must be protected in both bands. The Commission finds that a single third-party coordinator armed with knowledge of the operational guidelines imposed by prior coordination can cross reference that data with new requests for coordination in real time and act as an intermediary with SBE and NTIA to speed up the review process and thus expedite deployment in the bands. Absent the assistance of a centralized coordinator familiar with the operational and protection needs of non-Federal operators and Federal incumbents as well as the terms of previously completed launch coordination, individual space launch operators will find it far more difficult to navigate the requisite layers of approval in a timely fashion, particularly considering the short turnaround times and multi-factored variability of space launches and the fluctuating needs of Federal users in these heavily trafficked bands. Having a third-party entity perform those duties on behalf of the operators will streamline the coordination process, offer greater flexibility to operators as they approach scheduled launch dates, and ensure protection for incumbent operations against harmful interference.</P>
                <P>Accordingly, the Commission hereby adopts a post-license grant coordination regime that will be facilitated by a third-party space launch frequency coordinator and require a two-part process: (1) for the 2025-2110 MHz band, a site-specific coordination of the operator's stations and launch parameters with BAS operations; and (2) for both bands, coordination on a per-launch basis with NTIA. In practice, as described in more detail below, coordination processes for the two bands will be different given the existing 2025-2110 MHz coordination process currently conducted by SBE to protect BAS, CARS, and LTTS operations and previously coordinated Federal incumbents in the band.</P>
                <P>
                    <E T="03">2025-2110 MHz Post-license Coordination (Earth-to-Space).</E>
                     Once a launch operator registers its site and corresponding station information with the Commission in ULS and it is made available to the space launch frequency coordinator, the coordinator will verify that the operator is licensed and then contact the SBE Frequency Coordination Manager and the relevant SBE local market coordinator for the 2025-2110 MHz band to initiate coordination for the local launch site to protect non-Federal incumbents.
                </P>
                <P>
                    For this process, the Commission adopts an approach that mirrors the coordination approach that Federal users in the band must follow. As noted in the 
                    <E T="03">FNPRM,</E>
                     Federal entities seeking to use the 2025-2110 MHz band for TT&amp;C uplink purposes must coordinate with all BAS and other non-Federal incumbents that may be affected by the Federal operation prior to submitting an application, and must engage the local BAS frequency coordinator(s) in support of achieving such coordination. In the context of pre-license grant coordination, the Commission sought comment on whether to require commercial space launch operators seeking to use the band to follow the same coordination process to help ensure that launch operations will not cause harmful interference to applicable non-Federal and Federal incumbents in the band. In its comments, SBE described this Federal precedent and pointed out that the terms of a subsequent SBE-NAB-DoD Memorandum of Understanding (MOU) are currently being used to coordinate Federal entities seeking to use the 2025-2110 MHz band for TT&amp;C uplink purposes. Engineers for the Integrity of Broadcast Auxiliary Services Spectrum (EIBASS), NAB, and SpaceX supported the use of the BAS coordination approach set forth in the SBE-NAB-DoD MOU.
                </P>
                <P>
                    Accordingly, the Commission adopts the same site-specific BAS coordination process (and any re-coordination of the launch site) for commercial space 
                    <PRTPAGE P="63309"/>
                    launch services for the Commission's post-license grant coordination regime. The Commission finds merit in SBE's suggestion that this means that each space launch communications operator, through a third-party space launch frequency coordinator, should either complete BAS coordination for its identified sites or provide a showing to the space launch frequency coordinator (a) that it has previously coordinated its proposed operations with the SBE Frequency Coordination Manager; (b) that it has ascertained that its proposal will not constrain, preclude, nor interfere with incumbents in the band, including BAS, CARS, and LTTS licensees; and (c) that it has demonstrated in a technical showing that its proposed operation will not create more than 0.5 dB increase in the noise threshold of a receiver at a fixed or temporary fixed electronic news gathering (ENG) receive site.
                </P>
                <P>The Commission does not anticipate that there is a need for a subsequent per-launch coordination with BAS as long as the site operation for the proposed launch is consistent with the technical characteristics and launch parameters that were successfully coordinated previously and complies with any conditions or agreements resulting from such prior coordination. In other words, there is no need to conduct a per-launch coordination with BAS if the operator/frequency coordinator can perform the technical calculations to show its proposed uplink operations will meet the SBE-NAB-DoD protection criteria. The Commission finds that this approach will streamline the coordination process with BAS, particularly for space launch operators who provide multiple launches over their license term with the same sites that were previously coordinated and retain the same technical and operational characteristics. The Commission notes, however, that if these conditions are not met then the site must be re-coordinated pursuant to the site-specific BAS coordination process outlined above.</P>
                <P>With respect to protecting Federal users in the band, the Commission will require coordination with NTIA on a post-grant, per-launch basis. This process will be initiated after the operator obtains its license and provides applicable launch site and corresponding station information to the Commission in ULS, and submits this data, along with its proposed operational parameters, in a coordination request to the third-party space launch frequency coordinator. Given the variability of space launches, per-launch coordination offers an effective means of protecting co-frequency Federal users in the 2025-2110 MHz band from any potentially harmful interference stemming from a particular launch. The Commission notes that per-launch coordination is particularly well suited for accommodating the changing nature of Federal spectrum use. As demonstrated by NTIA's Federal Government Spectrum Use Reports, Federal spectrum uses and needs continue to evolve over time. The timely nature of a per-launch coordination with NTIA, facilitated by a third-party frequency coordinator, would account for the fluctuating needs of Federal TT&amp;C used to track mobile satellites and the shifting demands of Federal mobile users that tend to change locations over time. The Commission contemplates a process that will be functionally similar to the current per-launch STA coordination procedures. As noted in the record, frequency coordination has been an effective tool in ensuring equitable spectrum sharing by co-frequency non-Federal and Federal users without causing harmful interference. While the Commission adopts baseline power and emissions standards to facilitate spectrum sharing and interoperability among Federal and non-Federal operations, as explained in further detail below, per-launch coordination will be critical in determining additional technical and operational parameters necessary to permit space launch operators to carry out missions without causing harmful interference to other users of the spectrum. Given the intermittent nature of space launch operations as well as evolving Federal spectrum uses, this targeted per-launch approach ensures timely and accurate guidance closer to the launch date by affording parties the flexibility to make adjustments necessary to protect co-frequency Federal users.</P>
                <P>
                    <E T="03">2200-2290 MHz Post-license Coordination (Space-to-Earth).</E>
                     Similarly, for the 2200-2290 MHz band, a space launch operator must identify applicable site and corresponding station information with the Commission in ULS and make it, along with its proposed operational details, available to the third-party space launch frequency coordinator, who verifies that the operator is licensed and that the request comports with rules, to initiate the coordination process with NTIA. Coordination with NTIA will be functionally similar to the current STA coordination process (
                    <E T="03">i.e.,</E>
                     site-specific and per-launch coordination with NTIA and the relevant Federal offices). Similar to the 2025-2110 MHz band, the coordination process will enable any necessary adjustments regarding the operational and technical parameters on a per-launch basis to protect against harmful interference.
                </P>
                <P>The Commission directs WTB to seek further comment on the circumstances attending the designation of a third-party space launch coordinator, including a mechanism for selecting a frequency coordinator. As noted, WTB will issue a public notice regarding the coordination process after reviewing the record, which will include information regarding the third-party frequency coordinator.</P>
                <HD SOURCE="HD1">Technical Rules for Space Launch Operations</HD>
                <P>
                    As noted in the 
                    <E T="03">FNPRM,</E>
                     the Commission seeks to establish technical parameters for commercial space launch operations that will support the evolving interests and requirements of commercial space entities while minimizing harmful interference between Federal and non-Federal operations. The Commission proposed that the current framework applicable to Federal operators would offer a predictable and tested model that facilitates the efficient use of spectrum while minimizing interference among users in these bands, and proposed to adopt a similar set of technical rules for non-Federal space launch operations in the 2200-2290 MHz and 2025-2110 MHz bands. The Commission finds that adopting baseline emissions and power limits similar to that which currently apply to Federal operations will facilitate interoperability and greater predictability regarding operations in these bands. As discussed previously, however, the variability of space launches and the changing needs of Federal operations may require additional or alternative technical requirements for a given launch as determined pursuant to the coordination process. The Commission concludes that adopting a technical framework that relies on close coordination between Federal and non-Federal entities as well as the use of similar emissions and power limits will help users of the bands to avoid harmful interference while allowing commercial launch providers to benefit from the economies of scale inherent from using the same communications systems for both Federal agencies and commercial customers.
                </P>
                <HD SOURCE="HD1">2200-2290 MHz Band</HD>
                <P>
                    The 
                    <E T="03">FNPRM</E>
                     noted that space launch operations may potentially operate under a dual regulatory approach, and 
                    <PRTPAGE P="63310"/>
                    sought comment on the appropriate technical requirements under both a space operations and aeronautical mobile allocation. The Commission asked whether these technical rules align with NTIA's requirements for both Federal and non-Federal space operations and how the Commission might promote consistency between and among the various, similarly situated services authorized in the band.
                </P>
                <P>
                    <E T="03">Emission masks.</E>
                     In the 
                    <E T="03">FNPRM,</E>
                     the Commission sought comment on whether to apply NTIA rules that require that earth and space stations in the space operations service above 470 MHz comply with the emissions mask standard established in section 5.6.2 of the NTIA Manual. Section 5.6.2 provides that for frequencies offset from the assigned frequency less than the 50 percent of the necessary bandwidth, no attenuation is required. At a frequency offset equal to 50 percent of the necessary bandwidth, an attenuation of at least 8 dB is required, while frequencies offset more than 50 percent of the necessary bandwidth should be attenuated in accordance with a specified formula dependent on necessary bandwidth and frequency displaced from the center of the emission bandwidth.
                </P>
                <P>
                    Further, the Commission noted that section 5.3.9 of the NTIA Manual provides that aeronautical telemetry operations in the 2200-2290 MHz band must meet the emissions limits from Chapter 2 of the Inter-Range Instrumentation Group (IRIG) Standard 106-15, part 1. Chapter 2 of IRIG Standard 106-15, part 1 (hereinafter IRIG Standard 106-15), in turn, includes the following aeronautical telemetry spectral mask: all spectral components larger than −[55 + 10xlog(P)] dBc (
                    <E T="03">i.e.,</E>
                     larger than −25 dBm) at the transmitter output must be within the spectral mask calculated using the following equation:
                </P>
                <FP SOURCE="FP-2">M(f) = K + 90 log(R)−100 log |f-fc|; |f-fc| ≥ R/m</FP>
                <EXTRACT>
                    <FP SOURCE="FP-2">Where</FP>
                    <FP SOURCE="FP-2">M(f) = power (dBc) at frequency f (MHz)</FP>
                    <FP SOURCE="FP-2">K = −20 for analog signals</FP>
                    <FP SOURCE="FP-2">K = −28 for binary signals</FP>
                    <FP SOURCE="FP-2">K = −61 for FQPSK-B, FQPSK-JR, SOQPSK-TG</FP>
                    <FP SOURCE="FP-2">K = −73 for ARTM CPM</FP>
                    <FP SOURCE="FP-2">fc = transmitter center frequency (MHz)</FP>
                    <FP SOURCE="FP-2">R = bit rate (Mbps) for digital signals or (Δf +fmax)(MHz) for analog FM signals</FP>
                    <FP SOURCE="FP-2">M = number of states in modulating signal (m = 2 for binary signals, m = 4 for quaternary signals and analog signals)</FP>
                    <FP SOURCE="FP-2">Δf = peak deviation</FP>
                    <FP SOURCE="FP-2">fmax = maximum modulation frequency</FP>
                </EXTRACT>
                <P>The Commission also requested comment on the utility of using a single mask for non-Federal operations in the band rather than NTIA's dual emissions mask approach. The Commission asked, for example, whether to apply the section 5.6.2 space operations emissions mask to all stages of flight, or whether alternatively to apply emissions limits set forth in the Commission's rules for space stations found in part 25 or an alternative mask found in § 87.139.</P>
                <P>There was limited comment regarding the emissions limit(s) that should be applied. Of the few commenting on this issue, SpaceX supports the use of a single mask over NTIA's dual emissions mask approach, while ULA supports following NTIA's dual mask approach.</P>
                <P>The Commission agrees with ULA that it should adopt NTIA's dual mask approach, and the Commission's adoption of a Mobile allocation for this band facilitates this approach. As noted, NTIA regards launch vehicles as undergoing two stages: an aeronautical mobile stage and a space operation stage. The NTIA rules treat the telemetry system during the first stage of a launch vehicle as an aeronautical mobile system. The NTIA rules provide that after the first stage (which it views as the first 15 minutes of flight), the launch vehicle operates as a space operation service during the second stage or higher stages of a launch. As the Commission has noted, it seeks to align the technical parameters used by Federal and non-Federal operations to facilitate interoperability with respect to use of the 2200-2290 MHz band, and to provide predictability regarding such operations for other users of the band. While the Commission appreciates SpaceX's desire to avoid “artificial delineations,” the application of the dual approach best accommodates operations in this band as it is the approach that is already being utilized and which has proven to be effective in protecting operations in the band. Accordingly, the Commission will apply the dual aeronautical mobile and space operation emissions masks similar to those found in the NTIA rules.</P>
                <P>
                    <E T="03">Power limits.</E>
                     As noted in the 
                    <E T="03">FNPRM,</E>
                     the IRIG Standard 106-15 that NTIA applies to aeronautical telemetry in the 2200-2290 MHz band provides that the effective isotropic radiated power of a transmitter shall not exceed 25 watts and that the output power shall not exceed 25 watts. In contrast, NTIA's requirements for space operations do not impose a power limit, and instead rely on a power flux-density limit established by the ITU. The 
                    <E T="03">FNPRM</E>
                     sought comment on whether, consistent with the NTIA rules, to limit first-stage operations to an effective isotropic radiated power of 25 watts and a transmitter output power of up to 25 watts, and sought comment on whether to apply a power flux-density limit on operations after the first stage. Alternatively, to the extent the Commission adopts a power flux-density limit in the band, the 
                    <E T="03">FNPRM</E>
                     asked whether no further limit on power is necessary, or whether the Commission should adopt an alternative to the power limit in IRIG Standard 106-15.
                </P>
                <P>As in the case of emissions masks, the Commission received limited comment on this issue. ULA argues that these limits are appropriate for aeronautical applications, but not for orbital launches. SpaceX supports the adoption of a single power flux-density limit for all aspects of launch operations rather than the use of power limits.</P>
                <P>
                    Upon review, the Commission finds that it is in the public interest to apply the dual stage aeronautical mobile and space operations approach for power limits as specified in the NTIA rules. While the Commission recognizes that there may be individual launch operations that requires the use of technical parameters outside of the norm, there is insufficient information in the record that would support deviation from limits currently used by NTIA during the first/ascent stage—either with respect to a power increase or to the use of a power flux-density limit. Neither would serve the Commission's goal of facilitating interoperability with Federal launch operations. With respect to ULA's request to adopt much higher power limits to support orbital launches, the Commission concludes that any orbital flight phase would be better governed by established space operation requirements, 
                    <E T="03">i.e.</E>
                     the NTIA/ITU space operation power flux-density limit. Further, the Commission does not find the use of the space operation power flux-density limit for all phases of a launch to be appropriate given that, as ULA notes, launch vehicles remain too close to the Earth's surface during the launch phase to comply with the limit. Moreover, neither commenter discusses the impact of their proposals on other users of the 2200-2290 MHz band. Absent support that these proposals would not adversely affect other operations in the band and provide advantages to commercial space launch entities that would exceed those that result from being able to operate with both Federal and non-Federal launch systems, the Commission finds it appropriate to follow the NTIA dual stage approach.
                </P>
                <P>
                    The 
                    <E T="03">FNPRM</E>
                     sought comment regarding the point at which the Commission should apply the ITU 
                    <PRTPAGE P="63311"/>
                    power-flux density limits in the event the Commission adopts the dual aeronautical mobile and space operation service approach. The Commission finds it appropriate to apply the NTIA aeronautical mobile power limits to first stage launch operations (first 15 minutes of flight) and ITU-derived space operation power flux-density limits to launch operations beyond the first stage. The Commission will adopt the NTIA approach which regards the first stage of a launch as an aeronautical mobile operation and treats the second stage or higher stages of a launch as space operations. While Rocket Lab and NASA note the difficulties associated with defining the dividing line between aeronautical mobile operations and space operations according to launch stages, the Commission finds that doing so provides a predictable approach and permits the similar treatment of Federal and non-Federal space launch operations. To the extent that this approach presents technical issues for a given launch (for example, the approach would require the application of the power flux-density limit too early in a launch), operators may seek a waiver of this provision.
                </P>
                <HD SOURCE="HD1">2025-2110 MHz Band</HD>
                <P>
                    <E T="03">Emissions Limits.</E>
                     As discussed in the 
                    <E T="03">FNPRM,</E>
                     the most analogous authorized Federal operation in the 2025-2110 MHz band is earth station telecommand transmissions to spacecraft, which operate under space operations rules. As discussed above, NTIA requires that earth and space stations in the space operations service above 470 MHz comply with the emissions mask standards established in section 5.6.2 of the NTIA Manual. Section 5.6.2 provides that for frequencies offset from the assigned frequency less than the 50 percent of the necessary bandwidth, no attenuation is required. At a frequency offset equal to 50 percent of the necessary bandwidth, an attenuation of at least 8 dB is required, while frequencies offset more than 50 percent of the necessary bandwidth should be attenuated in accordance with a specified formula dependent on necessary bandwidth and frequency displaced from the center of the emission bandwidth. The 
                    <E T="03">FNPRM</E>
                     proposed to adopt the NTIA's emissions mask for commercial space launch transmissions in the 2025-2110 MHz band, except that the Commission proposed to apply attenuation requirements to the licensee's assigned frequencies rather than requiring a separate calculation of necessary bandwidth.
                </P>
                <P>SpaceX agrees that the Commission should apply the emissions mask applicable to space operation service for operations in the 2025-2110 MHz band. Other than SpaceX, the Commission received no other comment regarding the appropriate emissions limit for this band. Accordingly, in line with the Commission's overall approach for space launch technical rules, the Commission will apply an emissions mask using the same limit as that set forth in section 5.6.2 of the NTIA Manual.</P>
                <P>
                    Further, the Commission will retain the provision in section 5.6.2 which specifies attenuation requirements based on a separate calculation of necessary bandwidth. Although SpaceX supports the 
                    <E T="03">FNPRM's</E>
                     proposal to apply attenuation requirements based on a licensee's assigned frequencies, the Commission finds that it is more appropriate to apply the same methodology that is used currently. Given that the Commission seeks to apply a technical framework that provides predictability and minimizes the risk of interference among users in the band, the Commission finds that applying the section 5.6.2 methodology will provide consistency and prevent confusion. Accordingly, the Commission will not adopt its proposal to permit space launch operators to determine applicable attenuation requirements using the licensee's assigned frequencies.
                </P>
                <P>
                    <E T="03">Power limits.</E>
                     Section 8.2.35 of the NTIA manual requires that the EIRP transmitted in any direction towards the horizon by a Federal earth station in bands between 1 GHz and 15 GHz that are shared with stations in the fixed or mobile service, which includes the 2025-2110 MHz band, shall not (with limited exceptions) exceed the following limits:
                </P>
                <FP SOURCE="FP-2">
                    +40 dBW in any 4 kHz band for 
                    <E T="8153">u</E>
                     ≤0°
                </FP>
                <FP SOURCE="FP-2">
                    +40+3
                    <E T="8153">u</E>
                     dBW in any 4 kHz band for 0°&lt; 
                    <E T="8153">u</E>
                     ≤5°
                </FP>
                <EXTRACT>
                    <FP SOURCE="FP-2">Where:</FP>
                    <FP SOURCE="FP-2">
                        <E T="8153">u</E>
                         is the angle of elevation of the horizon viewed from the center of radiation of the antenna of the earth station and measured in degrees as positive above the horizontal plane and negative below it.
                    </FP>
                </EXTRACT>
                <P>As in the case with the 2200-2290 MHz band, SpaceX supports adoption of a single power flux-density limit for all aspects of launch operations in lieu of a specific power limit on the grounds that it would obviate the need for any additional limitations on power or for adopting artificial distinctions between various launch activities.</P>
                <P>As the Commission noted with respect to SpaceX's proposal to apply a power flux-density limit to 2200-2290 MHz band operations, SpaceX does not provide sufficient information regarding the impact to other users of the 2025-2110 MHz band and provides no support as to whether using the space operation power flux-density limit will adequately protect other operations. Instead, SpaceX mainly argues that adopting a single flux-density limit for all aspects of a launch operation will simplify compliance for launch operators. While the Commission seeks to adopt rules that will help space launch entities to simplify or streamline operations, it is necessary that any measures that the Commission takes will also ensure that other users of the band are protected. Further, although SpaceX argues that ITU and NTIA regulations permit the use of the power flux-density limit for the 2025-2110 MHz band, the power limits above are the requirements that both ITU and NTIA specify for earth stations in bands that are shared with stations in the fixed or mobile service. Accordingly, the Commission adopts the same power limits as those set forth in section 8.2.35 of the NTIA Manual.</P>
                <P>
                    <E T="03">Compliance with technical specifications.</E>
                     In its Reply Comments, Northrop Grumman notes that because launch providers operate from Federal launch sites, launch vehicles and associated ground stations meet applicable Federal technical requirements, including emission limits, power limits, and power flux-density limits. Northrop Grumman recommends that, to ensure consistency and to avoid differing standards among launch sites, the Commission permit operators to demonstrate compliance with either (1) any new FCC requirements adopted in this proceeding or (2) existing Federal requirements serving the same purpose. Northrop Grumman argues that the latter is necessary to ensure that any new rules that the Commission apply to launch vehicle operators do not require that existing launch equipment be redesigned or modified or be subject to further regulatory requirements. Alternatively, Northrop Grumman argues that if the Commission imposes new technical standards, it should grandfather existing operators and exempt their current launch vehicles from these requirements. Northrop Grumman asserts that this flexibility is necessary to ensure that the application of any new technical standards does not delay or impact upcoming launches or require that existing launch vehicles be 
                    <PRTPAGE P="63312"/>
                    modified or subject to further regulatory requirements.
                </P>
                <P>While the Commission seeks to adopt rules that will facilitate the continued growth of the commercial space launch sector, and avoid policies that will negatively impact launch operations, the Commission is hesitant to grandfather operations that may not meet current required technical specifications. For example, Northrop Grumman notes that transmitters on its launch vehicles are designed to meet IRIG Standard 106-07, a previous IRIG Standard 106 version. While that standard shares many of the specifications as IRIG Standard 106-15, it is not clear that the use of IRIG Standard 106-07 or other standards meet all necessary technical specifications set forth here or in current NTIA requirements, and accordingly, the Commission is not prepared at this juncture to grandfather all existing launch vehicles.</P>
                <HD SOURCE="HD1">Equipment Authorization</HD>
                <P>
                    In the 
                    <E T="03">FNPRM,</E>
                     the Commission asked whether it should require part 2 equipment authorization for the radio frequency (RF) devices that are being used to provide space launch operations and if so, which procedure. The Commission also asked if there any analogous authorization models found in other any rule parts (specifically noting parts 25, 87, and 90) that could provide additional or alternative compliance requirements that may be appropriate for space launch RF devices.
                </P>
                <P>Few comments addressed the issue of equipment authorization. ULA and Boeing both oppose specific equipment authorization rules, citing, in part, the current part 25 rules that do not include such requirements. Northrop Grumman “takes no position” on such requirements, however it does ask for a 5 year grandfathered period should the Commission decide to adopt rules in this regard.</P>
                <P>The Commission shall not require that equipment used for space launch telemetry and telecommand during space launches under the part 26 rules be authorized under 47 CFR part 2, subpart J. The Commission expects that this equipment will be deployed by a limited number of licensees who will be responsible for ensuring that their transmitters comply with Commission's rules. Given the small number of licensees the Commission does not believe there is utility in implementing an authorization requirement. This decision is consistent with the Commission's part 87 rules which exempt flight test transmitters used for limited periods from needing equipment certification.</P>
                <HD SOURCE="HD1">Expanded Federal Use of the Non-Federal Fixed Satellite Service (FSS) and Mobile Satellite Service (MSS) Bands</HD>
                <P>
                    In the 2013 
                    <E T="03">NPRM</E>
                     (78 FR 39200, July 1, 2013), the Commission specifically sought comment on two proposals for expanding Federal use of non-Federal FSS and MSS satellites. One proposal was to add co-primary Federal FSS or MSS allocations to several bands together with a footnote that limits primary Federal use of the bands to earth stations communicating with non-Federal space stations. The other proposal was to add a footnote to the Table of Allocations outlining circumstances under which Federal earth stations operating with non-Federal space stations would be entitled to interference protection. In the 
                    <E T="03">FNPRM,</E>
                     the Commission sought to refresh the record on its proposals for expanding Federal use of non-Federal FSS and MSS satellites, noting that in the eight years since the 
                    <E T="03">NPRM</E>
                     was adopted “the spectrum landscape in non-Federal FSS and MSS allocations has changed significantly.”
                </P>
                <P>The Commission continues to believe that improvements to its policies and processes for communications between earth stations utilized by government agencies and commercial satellites are desirable and may ultimately serve the public interest. However, the Commission believes that this issue, while related to space launch operations generally, implicates different licensing processes and ultimately would require implementation distinct from the changes to launch frequency licensing the Commission is adopting here. Therefore, the Commission concludes that Federal access would be better addressed through a separate proceeding specifically focused on communications between commercial satellites and Federal users. Accordingly, the Commission will continue to examine the record on expanded Federal earth station access to non-Federal FSS and MSS satellites through a separate proceeding, and the Commission welcomes continued comment and dialogue from both Federal and non-Federal stakeholders as it seeks to address this issue, incorporating by reference the record to date on this issue from this proceeding. The Commission directs the Office of Engineering and Technology (OET) to issue a public notice opening a new docket for comments on this issue and provides additional context for interested parties to provide additional comments. After receiving additional comments on this issue, OET is directed to develop a recommendation so as to enable Commission consideration not later than one year from the release of this item.</P>
                <HD SOURCE="HD1">Federal Space Stations in the 399.9-400.05 MHz MSS Band</HD>
                <P>
                    As requested by NTIA the Commission will revise footnote US319 of the Allocation Table to permit Federal space stations (
                    <E T="03">i.e.,</E>
                     satellites) to operate in the 399.9-400.05 MHz band. Currently, U.S. Table footnote US319 prevents Federal space stations from operating in the 399.9-400.05 MHz band even though there is a primary Federal Mobile Satellite Service allocation for this band. NTIA requests that the footnote be modified to delete the 399.9-400.05 MHz band thereby allowing Federal satellites to operate in this band. Footnote US319 currently provides that “US319: In the bands 137-138 MHz, 148-149.9 MHz, 149.9-150.05 MHz, 399.9-400.05 MHz, 400.15-401 MHz, 1610-1626.5 MHz, and 2483.5-2500 MHz, Federal stations in the mobile-satellite service shall be limited to earth stations operating with non-Federal space stations.”
                </P>
                <P>NTIA made this request to allow the 399.9-400.05 MHz band to be used for a new satellite system that will assume some of the non-environmental traffic currently handled by the Argos satellite system. Argos is a satellite system that was established by the French Space Agency, NASA, and the National Oceanic and Atmospheric Administration (NOAA). Argos is used for a large number of applications such as monitoring the oceans at thousands of fixed and drifting buoys, tracking the movements of wildlife, relaying information by humanitarian agencies from remote areas, monitoring water resources, and tracking the locations of ships. The latest version of the Argos satellite system, the Argos-4 was launched on October 7, 2022. According to NTIA, the newly established satellite system in the 399.9-400.05 MHz band would allow non-environmental applications to be removed from the Argos system which will result in lower interference, higher capacity, and improved reliability and service for both the environmental applications remaining on Argos and the non-environmental applications moved to the new system.</P>
                <P>
                    The Commission first made the 399.9-400.05 MHz band along with three other frequency bands available for MSS in 1993 to allow deployment of non-geosynchronous low Earth orbit (LEO) satellite systems, called “Little 
                    <PRTPAGE P="63313"/>
                    LEO” systems, to provide non-voice services such as data messaging and position determination. In 2019, the Commission's International Bureau initiated a processing round for non-voice non-geostationary systems in this band as well as the 400.15-401 MHz band. The Commission's Space Bureau has granted market access for the 399.9-400.05 MHz band to three of these applicants while other applications remain pending or have been withdrawn. In the past two years other companies have filed applications to operate in the 399.9-400.05 MHz band.
                </P>
                <P>
                    The Commission received four comments and two reply comments in response to the 
                    <E T="03">FNPRM.</E>
                     Myriota Pty Ltd. (Myriota) and Fleet Space Technologies Pty. Ltd. (Fleet) express concerns regarding the impact to Internet of Things (IoT) connectivity and the coordination requirements needed to ensure there will be no interference between non-Federal and Federal space stations in the 399.9-400.05 MHz band. According to Myriota, making this modification to US319 would permit an unidentified number of Federal satellites to operate in the band and leave commercial operators who have invested in the band without adequate safeguards to ensure their operations will not be constrained. Myriota suggests that if the Commission makes this modification to US319 it should adhere to the stated purpose of the modification by permitting only a single Argos satellite and that NTIA and NOAA should consider whether commercial satellite operators could meet their mission requirements rather than operating Federal satellites in the band. Fleet points out that the 399.9-400.05 MHz band is the only globally harmonized UHF band for commercial smallsat MSS and claims that permitting Federal satellites in the band would disrupt the coordination among commercial satellite operators and delay deployment of innovative MSS applications. Blacksky Global supports amending footnote US319 and believes that allowing the band to assume some of the traffic currently handled by the Argos system would alleviate the pressure from Federal systems in adjacent bands and result in relaxation of the coordination conditions on non-Federal systems in the 401-402 MHz band. NTIA and DoC both emphasize the need to implement this modification of footnote US319 to ensure that the role of the United States in the Argos-4 program can proceed without any risk to its operation.
                </P>
                <P>The Commission is revising US319 as NTIA requests to enable establishment of a new satellite system to supplement the Argos program to further the reliable provision of important services. The Commission appreciates the concerns expressed by Myriota and Fleet that the use of this band by a Federal satellite system may complicate the interference environment and create coordination burdens. However, any Federal satellites that will operate in the band and the associated earth stations will be subject to coordination between NTIA and the Commission. During this coordination process any issues regarding coexistence between the Federal and non-Federal systems can be addressed. As applicants who filed during the processing round indicated that they are capable of sharing with current and future licensees in these bands, the Commission is confident that at the conclusion of this coordination process the Federal satellites will be able to share the band with the existing systems without harmful interference occurring. As the demand for spectrum continues to increase the Commission must continue to look for opportunities to more intensively use spectrum where possible. Therefore, the Commission sees no reason to reject NTIA's request to modify US319.</P>
                <HD SOURCE="HD1">Ordering Clauses</HD>
                <P>
                    Accordingly, 
                    <E T="03">it is ordered</E>
                     that pursuant to sections 1, 2, 4(i), 5(c), 301, 303(c), 303(f), and 303(r) of the Communications Act of 1934, as amended, 47 U.S.C. 151, 152, 154(i), 155(c), 301, 303(c), 303(f), and 303(r), and § 1.411 of the Commission's rules, 47 CFR 1.411, the Second Report and Order 
                    <E T="03">is hereby adopted</E>
                    .
                </P>
                <P>
                    <E T="03">It is further ordered</E>
                     that the amendments of parts 2 and 26 of the Commission's rules as set forth in Appendix A of the Second Report and Order, 
                    <E T="03">are adopted</E>
                    , effective thirty (30) days after publication in the 
                    <E T="04">Federal Register</E>
                    , with the exception of §§ 26.106, 26.108, 26.202, and 26.301, which contain new or modified information collection requirements that require review by the Office of Management and Budget (OMB) under the Paperwork Reduction Act. The Commission directs the Wireless Telecommunications Bureau to announce the effective date of those information collections in a document published in the 
                    <E T="04">Federal Register</E>
                     after the Commission receives OMB approval, and directs the Wireless Telecommunications Bureau to cause these rule sections to be revised accordingly.
                </P>
                <P>
                    <E T="03">It is further ordered</E>
                     that the Office of the Secretary, Reference Information Center, 
                    <E T="03">shall send</E>
                     a copy of the Second Report and Order, including the Final Regulatory Flexibility Analysis and the Initial Regulatory Flexibility Analysis, to the Chief Counsel for Advocacy of the Small Business Administration.
                </P>
                <P>
                    <E T="03">It is further ordered</E>
                     that the Commission 
                    <E T="03">shall send</E>
                     a copy of the Second Report and Order in a report to be sent to Congress and the Government Accountability Office pursuant to the Congressional Review Act, see 5 U.S.C. 801(a)(1)(A).
                </P>
                <LSTSUB>
                    <HD SOURCE="HED">List of Subjects</HD>
                    <CFR>47 CFR Part 0</CFR>
                    <P>Authority delegations (Government agencies), Reporting and recordkeeping requirements, Telecommunications.</P>
                    <CFR>47 CFR Part 1</CFR>
                    <P>Administrative practice and procedure.</P>
                    <CFR>47 CFR Part 2</CFR>
                    <P>Radio, Space transportation and exploration, Telecommunications.</P>
                    <CFR>47 CFR Part 26</CFR>
                    <P>Incorporation by reference, Radio, Space transportation and exploration, Telecommunications. </P>
                </LSTSUB>
                <SIG>
                    <FP>Federal Communications Commission.</FP>
                    <NAME>Marlene Dortch,</NAME>
                    <TITLE>Secretary.</TITLE>
                </SIG>
                <HD SOURCE="HD1">Final Rules</HD>
                <P>For the reasons discussed in the preamble, the Federal Communications Commission amends 47 CFR chapter I as follows:</P>
                <PART>
                    <HD SOURCE="HED">PART 0—COMMISSION ORGANIZATION</HD>
                </PART>
                <REGTEXT TITLE="47" PART="0">
                    <AMDPAR>1. The authority citation for part 0 continues to read as follows:</AMDPAR>
                    <AUTH>
                        <HD SOURCE="HED">Authority:</HD>
                        <P> 47 U.S.C. 151, 154(i), 154(j), 155, 225, 409, and 1754, unless otherwise noted.</P>
                    </AUTH>
                </REGTEXT>
                <REGTEXT TITLE="47" PART="0">
                    <AMDPAR>2. Amend § 0.331 by adding paragraph (h) to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 0.331 </SECTNO>
                        <SUBJECT>Authority delegated.</SUBJECT>
                        <STARS/>
                        <P>
                            (h) 
                            <E T="03">Authority concerning space launch services programs and licensing.</E>
                             The Chief of the Wireless Telecommunications Bureau is delegated authority to administer the Commission's space launch services programs (part 26 of this chapter) and the issuing of space launch services licenses. The Chief is delegated authority to develop specific methods that will be used to develop an application filing procedure for initial authorization and subsequent station registration; to seek comment on the circumstances attending the designation 
                            <PRTPAGE P="63314"/>
                            of a third-party space launch frequency coordinator, including a mechanism for selecting a frequency coordinator; to develop procedures that the space launch frequency coordinator will use to ensure compliance with the coordination requirements for space launch operations; and to perform other functions as needed for the administration of the space launch services.
                        </P>
                    </SECTION>
                </REGTEXT>
                <PART>
                    <HD SOURCE="HED">PART 1—PRACTICE AND PROCEDURE </HD>
                </PART>
                <REGTEXT TITLE="47" PART="1">
                    <AMDPAR>3. The authority citation for part 1 continues to read as follows:</AMDPAR>
                    <AUTH>
                        <HD SOURCE="HED">Authority:</HD>
                        <P> 47 U.S.C. chs. 2, 5, 9, 13; 28 U.S.C. 2461 note; 47 U.S.C. 1754, unless otherwise noted.</P>
                    </AUTH>
                </REGTEXT>
                <REGTEXT TITLE="47" PART="1">
                    <AMDPAR>4. Revise § 1.901 to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 1.901 </SECTNO>
                        <SUBJECT>Basis and purpose.</SUBJECT>
                        <P>
                            This subpart is issued pursuant to the Communications Act of 1934, as amended, 47 U.S.C. 151 
                            <E T="03">et seq.</E>
                             The purpose of this subpart is to establish the requirements and conditions under which entities may be licensed in the Wireless Radio Services as described in this part and in parts 13, 20, 22, 24, 26, 27, 74, 80, 87, 90, 95, 96, 97, and 101 of this chapter.
                        </P>
                    </SECTION>
                </REGTEXT>
                <REGTEXT TITLE="47" PART="1">
                    <AMDPAR>5. Revise § 1.902 to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 1.902 </SECTNO>
                        <SUBJECT>Scope.</SUBJECT>
                        <P>In case of any conflict between the rules set forth in this subpart and the rules set forth in parts 13, 20, 22, 24, 26, 27, 74, 80, 87, 90, 95, 96, 97, and 101 of this chapter, the rules in this subpart shall govern.</P>
                    </SECTION>
                </REGTEXT>
                <REGTEXT TITLE="47" PART="1">
                    <AMDPAR>6. Amend § 1.907 by revising the definitions of “Covered geographic licenses” and “Wireless Radio Services” to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 1.907 </SECTNO>
                        <SUBJECT>Definitions.</SUBJECT>
                        <STARS/>
                        <P>
                            <E T="03">Covered geographic licenses.</E>
                             Covered geographic licenses consist of the following services: 1.4 GHz Service (part 27, subpart I, of this chapter); 1.6 GHz Service (part 27, subpart J); 24 GHz Service and Digital Electronic Message Services (part 101, subpart G, of this chapter); 218-219 MHz Service (part 95, subpart F, of this chapter); 220-222 MHz Service, excluding public safety licenses (part 90, subpart T, of this chapter); 600 MHz Service (part 27, subpart N); 700 MHz Commercial Services (part 27, subparts F and H); 700 MHz Guard Band Service (part 27, subpart G); 800 MHz Specialized Mobile Radio Service (part 90, subpart S); 900 MHz Specialized Mobile Radio Service (part 90, subpart S); 900 MHz Broadband Service (part 27, subpart P); 3.45 GHz Service (part 27, subpart Q); 3.7 GHz Service (part 27, subpart O); Advanced Wireless Services (part 27, subparts K and L); Air-Ground Radiotelephone Service (Commercial Aviation) (part 22, subpart G, of this chapter); Broadband Personal Communications Service (part 24, subpart E, of this chapter); Broadband Radio Service (part 27, subpart M); Cellular Radiotelephone Service (part 22, subpart H); Citizens Broadband Radio Service (part 96, subpart C, of this chapter); Dedicated Short Range Communications Service, excluding public safety licenses (part 90, subpart M); Educational Broadband Service (part 27, subpart M); H Block Service (part 27, subpart K); Local Multipoint Distribution Service (part 101, subpart L); Multichannel Video Distribution and Data Service (part 101, subpart P); Multilateration Location and Monitoring Service (part 90, subpart M); Multiple Address Systems (EAs) (part 101, subpart O); Narrowband Personal Communications Service (part 24, subpart D); Paging and Radiotelephone Service (part 22, subpart E; part 90, subpart P); VHF Public Coast Stations, including Automated Maritime Telecommunications Systems (part 80, subpart J, of this chapter); Space Launch Services (part 26 of this chapter); Upper Microwave Flexible Use Service (part 30 of this chapter); and Wireless Communications Service (part 27, subpart D).
                        </P>
                        <STARS/>
                        <P>
                            <E T="03">Wireless Radio Services.</E>
                             All radio services authorized in parts 13, 20, 22, 24, 26, 27, 74, 80, 87, 90, 95, 96, 97 and 101 of this chapter, whether commercial or private in nature.
                        </P>
                        <STARS/>
                    </SECTION>
                </REGTEXT>
                <PART>
                    <HD SOURCE="HED">PART 2—FREQUENCY ALLOCATIONS AND RADIO TREATY MATTERS; GENERAL RULES AND REGULATIONS </HD>
                </PART>
                <REGTEXT TITLE="47" PART="2">
                    <AMDPAR>7. The authority citation for part 2 continues to read as follows:</AMDPAR>
                    <AUTH>
                        <HD SOURCE="HED">Authority: </HD>
                        <P>47 U.S.C. 154, 302a, 303, and 336, unless otherwise noted.</P>
                    </AUTH>
                </REGTEXT>
                <REGTEXT TITLE="47" PART="2">
                    <AMDPAR>8. Amend § 2.106 by:</AMDPAR>
                    <AMDPAR>a. In paragraph (a), revising pages 26, 36, and 37;</AMDPAR>
                    <AMDPAR>b. Adding paragraph (c)(94); and</AMDPAR>
                    <AMDPAR>c. Revising paragraphs (c)(96) and (319).</AMDPAR>
                    <P>The revisions and addition read as follows:</P>
                    <SECTION>
                        <SECTNO>§ 2.106 </SECTNO>
                        <SUBJECT>Table of Frequency Allocations.</SUBJECT>
                        <P>(a) * * *</P>
                        <BILCOD>BILLING CODE 6712-01-P</BILCOD>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="63315"/>
                            <GID>ER05AU24.000</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="63316"/>
                            <GID>ER05AU24.001</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="63317"/>
                            <GID>ER05AU24.002</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="63318"/>
                            <GID>ER05AU24.003</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="63319"/>
                            <GID>ER05AU24.004</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="63320"/>
                            <GID>ER05AU24.005</GID>
                        </GPH>
                        <BILCOD>BILLING CODE 6712-01-C</BILCOD>
                        <PRTPAGE P="63321"/>
                        <STARS/>
                        <P>(c) * * *</P>
                        <P>(94) US94 In the band 2025-2110 MHz, the non-Federal space operation service shall be subject to the following conditions:</P>
                        <P>(i) Transmissions are restricted to telecommand use for pre-launch testing and space launch operations.</P>
                        <P>(ii) Subject to coordination with the National Telecommunications and Information Administration (NTIA) prior to each launch.</P>
                        <P>(iii) Subject to coordination with non-Federal fixed and mobile stations.</P>
                        <STARS/>
                        <P>(96) US96 The band 2200-2290 MHz is allocated to the space operation service (space-to-Earth) and mobile service on a secondary basis for non-Federal use subject to the following conditions. Non-Federal stations shall be:</P>
                        <P>(i) Restricted to use for pre-launch testing and space launch operations, except as provided under US303; and</P>
                        <P>(ii) Subject to coordination with NTIA prior to each launch.</P>
                        <STARS/>
                        <P>(319) US319 In the bands 137-138 MHz, 148-149.9 MHz, 149.9-150.05 MHz, 400.15-401 MHz, 1610-1626.5 MHz, and 2483.5-2500 MHz, Federal stations in the mobile-satellite service shall be limited to earth stations operating with non-Federal space stations.</P>
                        <STARS/>
                    </SECTION>
                </REGTEXT>
                <REGTEXT TITLE="47" PART="26">
                    <AMDPAR>9. Add part 26 to read as follows:</AMDPAR>
                    <PART>
                        <HD SOURCE="HED">PART 26—SPACE LAUNCH SERVICES</HD>
                        <CONTENTS>
                            <SUBPART>
                                <HD SOURCE="HED">Subpart A—General Information</HD>
                                <SECHD>Sec.</SECHD>
                                <SECTNO>26.1 </SECTNO>
                                <SUBJECT>Basis and purpose.</SUBJECT>
                                <SECTNO>26.2 </SECTNO>
                                <SUBJECT>Frequencies.</SUBJECT>
                                <SECTNO>26.3 </SECTNO>
                                <SUBJECT>Scope of service.</SUBJECT>
                                <SECTNO>26.4 </SECTNO>
                                <SUBJECT>Other applicable rule parts.</SUBJECT>
                                <SECTNO>26.5 </SECTNO>
                                <SUBJECT>Terms and definitions.</SUBJECT>
                            </SUBPART>
                            <SUBPART>
                                <HD SOURCE="HED">Subpart B—Applications and Licenses</HD>
                                <SECTNO>26.101 </SECTNO>
                                <SUBJECT>Eligibility.</SUBJECT>
                                <SECTNO>26.102 </SECTNO>
                                <SUBJECT>License period; renewal.</SUBJECT>
                                <SECTNO>26.103 </SECTNO>
                                <SUBJECT>Licensing.</SUBJECT>
                                <SECTNO>26.104 </SECTNO>
                                <SUBJECT>Regulatory status.</SUBJECT>
                                <SECTNO>26.105 </SECTNO>
                                <SUBJECT>Authorization required.</SUBJECT>
                                <SECTNO>26.106 </SECTNO>
                                <SUBJECT>[Reserved]</SUBJECT>
                                <SECTNO>26.107 </SECTNO>
                                <SUBJECT>Restrictions on the operation of stations.</SUBJECT>
                                <SECTNO>26.108 </SECTNO>
                                <SUBJECT>[Reserved]</SUBJECT>
                                <SECTNO>26.109 </SECTNO>
                                <SUBJECT>Assignment and transfer.</SUBJECT>
                            </SUBPART>
                            <SUBPART>
                                <HD SOURCE="HED">Subpart C—Frequency Coordination</HD>
                                <SECTNO>26.201 </SECTNO>
                                <SUBJECT>Policies governing the assignment of frequencies.</SUBJECT>
                                <SECTNO>26.202 </SECTNO>
                                <SUBJECT>[Reserved]</SUBJECT>
                            </SUBPART>
                            <SUBPART>
                                <HD SOURCE="HED">Subpart D—Technical Standards</HD>
                                <SECTNO>26.301 </SECTNO>
                                <SUBJECT>[Reserved]</SUBJECT>
                                <SECTNO>26.302 </SECTNO>
                                <SUBJECT>Emission masks.</SUBJECT>
                                <SECTNO>26.303 </SECTNO>
                                <SUBJECT>Power limits.</SUBJECT>
                                <SECTNO>26.304 </SECTNO>
                                <SUBJECT>Antenna structures; air navigation safety.</SUBJECT>
                                <SECTNO>26.305 </SECTNO>
                                <SUBJECT>Incorporation by reference.</SUBJECT>
                            </SUBPART>
                        </CONTENTS>
                        <AUTH>
                            <HD SOURCE="HED">Authority: </HD>
                            <P>47 U.S.C. 151, 152, 154, 301, 303, unless otherwise noted.</P>
                        </AUTH>
                        <SUBPART>
                            <HD SOURCE="HED">Subpart A—General Information</HD>
                            <SECTION>
                                <SECTNO>§ 26.1 </SECTNO>
                                <SUBJECT>Basis and purpose.</SUBJECT>
                                <P>This section contains the statutory basis for the rules in this part and provides the purpose for which this part is issued.</P>
                                <P>
                                    (a) 
                                    <E T="03">Basis.</E>
                                     The rules for Space Launch Services in this part are promulgated under the provisions of the Communications Act of 1934, as amended, that vest authority in the Federal Communications Commission (Commission or FCC) to regulate radio transmission and to issue licenses for radio stations. All rules in this part are in accordance with applicable treaties and agreements to which the United States is a party.
                                </P>
                                <P>
                                    (b) 
                                    <E T="03">Purpose.</E>
                                     This part states the conditions under which spectrum is made available and licensed for the provision of Space Launch Services. This part does not govern the licensing of radio systems belonging to and operated by the United States.
                                </P>
                            </SECTION>
                            <SECTION>
                                <SECTNO>§ 26.2 </SECTNO>
                                <SUBJECT>Frequencies.</SUBJECT>
                                <P>The following frequencies are available for assignment on a nationwide, non-exclusive basis for Space Launch Services:</P>
                                <P>(a) 2025-2110 MHz; and</P>
                                <P>(b) 2200-2290 MHz.</P>
                            </SECTION>
                            <SECTION>
                                <SECTNO>§ 26.3 </SECTNO>
                                <SUBJECT>Scope of service.</SUBJECT>
                                <P>(a) Space launch stations are restricted to the following uses:</P>
                                <P>
                                    (1) 
                                    <E T="03">2025-2110 MHz band.</E>
                                     The use of Space Launch Services licenses in the 2025-2110 MHz band is restricted to ground-to-launch vehicle telecommand uses necessary to support space launch operations.
                                </P>
                                <P>
                                    (2) 
                                    <E T="03">2200-2290 MHz band.</E>
                                     The use of Space Launch Services licenses in the 2200-2290 MHz band is restricted to launch vehicle-to-ground communications associated with telemetry and tracking operations.
                                </P>
                                <P>(b) Telemetry, tracking, and telecommand functions permissible as space launch operations include, but are not limited to:</P>
                                <P>(1) Pre-launch testing, such as pre-flight checks, ground testing, and telemetry;</P>
                                <P>(2) Vehicle tracking, including the transmission of parameter data from a launch vehicle to ground;</P>
                                <P>(3) Telecommand signals for propulsive maneuvering of a launch vehicle and separation of payload from launch vehicle; and</P>
                                <P>(4) Telecommand signals for propulsive maneuvering of a reentry vehicle for return and recovery.</P>
                                <P>(c) The use of Space Launch Services licenses for on-orbit communications after a launch vehicle separates from its payload are not permitted, provided that a space launch station may be used for telemetry, tracking, and telecommand activities for the incidental orbiting of a launch vehicle before or after it has separated from its payload. The use of Space Launch Services licenses for such incidental orbiting are permitted only to the extent necessary for space launch operations.</P>
                            </SECTION>
                            <SECTION>
                                <SECTNO>§ 26.4 </SECTNO>
                                <SUBJECT>Other applicable rule parts.</SUBJECT>
                                <P>Other FCC rule parts applicable to the Space Launch Services include the following:</P>
                                <P>
                                    (a) 
                                    <E T="03">Part 0.</E>
                                     Part 0 of this chapter describes the Commission's organization and delegations of authority. Part 0 also lists available Commission publications, standards, and procedures for access to Commission records, and location of Commission Field Offices.
                                </P>
                                <P>
                                    (b) 
                                    <E T="03">Part 1.</E>
                                     Part 1 of this chapter includes rules of practice and procedure for license applications, adjudicatory proceedings, procedures for reconsideration and review of the Commission's actions; provisions concerning violation notices and forfeiture proceedings; competitive bidding procedures; and the environmental requirements that, together with the procedures specified in § 17.4(c) of this chapter, if applicable, must be complied with prior to the initiation of construction. Subpart F of part 1 includes the rules for the Wireless Radio Services and the procedures for filing electronically via the Universal Licensing System (ULS).
                                </P>
                                <P>
                                    (c) 
                                    <E T="03">Part 2.</E>
                                     Part 2 of this chapter contains the Table of Frequency Allocations and special requirements in international regulations, recommendations, agreements, and treaties. Part 2 also contains standards and procedures concerning the marketing and importation of radio frequency devices, and for obtaining equipment authorization.
                                </P>
                                <P>
                                    (d) 
                                    <E T="03">Part 5.</E>
                                     Part 5 of this chapter contains rules prescribing the manner in which parts of the radio frequency spectrum may be made available for experimentation.
                                </P>
                                <P>
                                    (e) 
                                    <E T="03">Part 15.</E>
                                     Part 15 of this chapter sets forth the requirements and conditions applicable to certain radio frequency devices.
                                </P>
                                <P>
                                    (f) 
                                    <E T="03">Part 17.</E>
                                     Part 17 of this chapter contains requirements for the construction, marking and lighting of 
                                    <PRTPAGE P="63322"/>
                                    antenna towers, and the environmental notification process that must be completed before filing certain antenna structure registration applications.
                                </P>
                                <P>
                                    (g) 
                                    <E T="03">Part 25.</E>
                                     Part 25 of this chapter contains the requirements for satellite communications, including satellite digital audio radio service (DARS).
                                </P>
                                <P>
                                    (h) 
                                    <E T="03">Part 74.</E>
                                     Part 74 of this chapter sets forth the requirements and conditions applicable to experimental radio, auxiliary, special broadcast, and other program distributional services.
                                </P>
                                <P>
                                    (i) 
                                    <E T="03">Part 87.</E>
                                     Part 87 of this chapter sets forth the requirements and conditions applicable to aviation services.
                                </P>
                            </SECTION>
                            <SECTION>
                                <SECTNO>§ 26.5 </SECTNO>
                                <SUBJECT>Terms and definitions.</SUBJECT>
                                <P>
                                    <E T="03">Base station.</E>
                                     A station at a specified site authorized to communicate with mobile stations.
                                </P>
                                <P>
                                    <E T="03">Equivalent isotropically radiated power</E>
                                     (
                                    <E T="03">EIRP</E>
                                    ). The product of the power supplied to the antenna and the antenna gain in a given direction relative to an isotropic antenna (absolute or isotropic gain).
                                </P>
                                <P>
                                    <E T="03">Expendable launch vehicle.</E>
                                     A launch vehicle whose propulsive stages are used only once.
                                </P>
                                <P>
                                    <E T="03">First stage of a launch.</E>
                                     The first 15 minutes of flight.
                                </P>
                                <P>
                                    <E T="03">Fixed service.</E>
                                     A radio communication service between specified fixed points.
                                </P>
                                <P>
                                    <E T="03">Fixed station.</E>
                                     A station in the fixed service.
                                </P>
                                <P>
                                    <E T="03">Frequency coordination.</E>
                                     The process of obtaining the recommendation of a frequency coordinator for a frequency(ies) that will most effectively meet the applicant's needs while minimizing interference to licensees already operating within a given frequency band.
                                </P>
                                <P>
                                    <E T="03">Frequency coordinator.</E>
                                     An entity or organization that has been certified by the Commission to recommend frequencies for use by licensees in the Space Launch Services.
                                </P>
                                <P>
                                    <E T="03">Harmful interference.</E>
                                     For the purposes of resolving conflicts between stations operating under this part, any emission, radiation, or induction which specifically degrades, obstructs, or interrupts the service provided by such stations.
                                </P>
                                <P>
                                    <E T="03">Itinerant operation.</E>
                                     Operation of a radio station at unspecified locations for varying periods of time.
                                </P>
                                <P>
                                    <E T="03">Launch vehicle.</E>
                                     A vehicle built to place a payload or human beings from Earth in a suborbital trajectory, in Earth orbit, or otherwise in outer space.
                                </P>
                                <P>
                                    <E T="03">Mobile service.</E>
                                     A radio communication service between mobile and land stations, or between mobile stations.
                                </P>
                                <P>
                                    <E T="03">Mobile station.</E>
                                     A station in the mobile service intended to be used while in motion or during halts at unspecified points.
                                </P>
                                <P>
                                    <E T="03">Reentry vehicle.</E>
                                     A vehicle designed to return from Earth orbit or outer space to Earth substantially intact. A reentry vehicle is regarded as a launch vehicle in the context of a space launch operation only to the extent that it is being used for launch purposes.
                                </P>
                                <P>
                                    <E T="03">Reusable launch vehicle.</E>
                                     A launch vehicle that is designed to return to Earth substantially intact and may be launched more than one time or that contains vehicle stages that may be recovered by a launch operator for future use.
                                </P>
                                <P>
                                    <E T="03">Space launch operations.</E>
                                     Any activity that places a launch vehicle, whether an expendable launch vehicle or a reusable launch vehicle or reentry vehicle used for launch, and any payload or human being from Earth in a suborbital trajectory, in Earth orbit, or otherwise in outer space, including pre-launch testing and recovery or reentry of the launch vehicle.
                                </P>
                                <P>
                                    <E T="03">Telecommand.</E>
                                     The transmission of non-voice signals for the purpose of remotely controlling a device.
                                </P>
                                <P>
                                    <E T="03">Telemetry.</E>
                                     The transmission of non-voice signals for the purpose of automatically indicating or recording measurements at a distance from the measuring instrument. In the context of space launch operations, telemetry is diagnostic information, transmitted from the launch vehicle to ground controller stations during the flight, which allows the ground controller station to track the performance of the launch vehicle.
                                </P>
                                <P>
                                    <E T="03">Universal Licensing System</E>
                                     (
                                    <E T="03">ULS</E>
                                    ). The consolidated database, application filing system, and processing system for all Wireless Telecommunications Services. The ULS offers Wireless Telecommunications Bureau (WTB) applicants and the general public electronic filing of all applications requests, and full public access to all WTB licensing data.
                                </P>
                            </SECTION>
                        </SUBPART>
                        <SUBPART>
                            <HD SOURCE="HED">Subpart B—Applications and Licenses</HD>
                            <SECTION>
                                <SECTNO>§ 26.101 </SECTNO>
                                <SUBJECT>Eligibility.</SUBJECT>
                                <P>The following entities are eligible for Space Launch Services licenses:</P>
                                <P>(a) A non-Federal entity that conducts space launch operations; or</P>
                                <P>(b) A parent of such entity or a subsidiary of such entity if either conducts space launch operations.</P>
                            </SECTION>
                            <SECTION>
                                <SECTNO>§ 26.102 </SECTNO>
                                <SUBJECT>License period; renewal.</SUBJECT>
                                <P>Licenses for stations in the Space Launch Services will be issued for a term of ten years from the date of original issuance, or renewal. Prior to expiration of the term of a license, the space launch licensee shall submit to the Commission an application for the renewal in accordance with part 1, subpart F, of this chapter. Such renewal application shall certify that, during the preceding license term, the licensee operated and continues to operate consistent with Commission rules in this chapter and the terms of its existing authorization, including the operation of stations consistent with the terms of frequency coordination performed during its license term.</P>
                            </SECTION>
                            <SECTION>
                                <SECTNO>§ 26.103 </SECTNO>
                                <SUBJECT>Licensing.</SUBJECT>
                                <P>The 2025-2110 MHz and 2200-2290 MHz bands are authorized on a non-exclusive nationwide basis for Space Launch Services. Non-exclusive nationwide licenses will serve as a prerequisite for registering launch sites and individual fixed, base, itinerant, and mobile stations, as well as individual coordinated launches. A Space Launch Services licensee cannot operate a launch site and corresponding fixed, base, itinerant, or mobile stations before registering it under its license and may only operate a station after that station has been cleared to operate in a particular frequency band in connection with a particular launch pursuant to the post-grant frequency coordination process set forth in subpart C of this part. Space Launch Services licensees must delete registrations for unused launch sites and unused fixed, base, itinerant, and mobile stations to maintain database integrity and facilitate coordination with other users of the 2025-2110 MHz and 2200-2290 MHz bands.</P>
                            </SECTION>
                            <SECTION>
                                <SECTNO>§ 26.104 </SECTNO>
                                <SUBJECT>Regulatory status.</SUBJECT>
                                <P>Licensees are permitted to provide services on a non-common carrier basis. A licensee may render communications services consistent with the regulatory status in its license and with the Commission's rules in this chapter applicable to the Space Launch Services.</P>
                            </SECTION>
                            <SECTION>
                                <SECTNO>§ 26.105 </SECTNO>
                                <SUBJECT>Authorization required.</SUBJECT>
                                <P>
                                    (a) 
                                    <E T="03">General rule.</E>
                                     Stations in the Space Launch Services must be used and operated only in accordance with the service rules set forth in this part, including the terms of the frequency coordination performed pursuant to subpart C of this part, and with a valid authorization granted by the Commission under the provisions of this part, except as specified in paragraph (b) of this section.
                                </P>
                                <P>
                                    (b) 
                                    <E T="03">Restrictions.</E>
                                     The holding of an authorization does not create any rights beyond the terms, conditions, and period specified in the authorization. 
                                    <PRTPAGE P="63323"/>
                                    Authorizations may be granted upon proper application, provided that the Commission finds that the applicant is qualified in regard to citizenship, character, financial, technical, and other criteria, and that the public interest, convenience, and necessity will be served. 
                                    <E T="03">See</E>
                                     47 U.S.C. 301, 308, 309, and 310.
                                </P>
                            </SECTION>
                            <SECTION>
                                <SECTNO>§ 26.106 </SECTNO>
                                <SUBJECT>[Reserved]</SUBJECT>
                            </SECTION>
                            <SECTION>
                                <SECTNO>§ 26.107 </SECTNO>
                                <SUBJECT>Restrictions on the operation of stations.</SUBJECT>
                                <P>Stations in the Space Launch Services may operate in a particular frequency band only if they have been registered pursuant to this subpart and cleared to operate in that frequency band by the space launch frequency coordinator using the frequency coordination process set forth in subpart C of this part.</P>
                            </SECTION>
                            <SECTION>
                                <SECTNO>§ 26.108 </SECTNO>
                                <SUBJECT>[Reserved]</SUBJECT>
                            </SECTION>
                            <SECTION>
                                <SECTNO>§ 26.109 </SECTNO>
                                <SUBJECT>Assignment and transfer.</SUBJECT>
                                <P>Licensees may assign or transfer their non-exclusive nationwide licenses upon application to and prior approval from the Commission, and any stations registered under those licenses will remain associated with those licenses unless otherwise agreed upon by the parties to the assignment or transfer and approved by the Commission.</P>
                            </SECTION>
                        </SUBPART>
                        <SUBPART>
                            <HD SOURCE="HED">Subpart C—Frequency Coordination</HD>
                            <SECTION>
                                <SECTNO>§ 26.201 </SECTNO>
                                <SUBJECT>Policies governing the assignment of frequencies.</SUBJECT>
                                <P>(a) Frequencies assigned to Space Launch Services stations are available on a shared basis only and will not be assigned for the exclusive use of any licensee.</P>
                                <P>(b) Any base, fixed, itinerant, or mobile station operating in the band must comply with the frequency coordination requirements set forth in this subpart.</P>
                                <P>
                                    (c) All applicants and licensees shall cooperate in the selection and use of frequencies for Space Launch Services and comply with the frequency coordination requirements in this subpart in order to minimize the potential for interference and make the most effective use of the authorized facilities. Information regarding registered launch sites, stations, and launches that have completed the frequency coordination process set forth in this subpart will be available at 
                                    <E T="03">https://wireless.fcc.gov/uls.</E>
                                     Licensees should examine this information before registering individual launch operations, and make every effort to ensure that their planned launch operations will not interfere or conflict with previously registered operations. Licensees of stations suffering or causing harmful interference are expected to cooperate and resolve this problem by mutually satisfactory arrangements.
                                </P>
                            </SECTION>
                            <SECTION>
                                <SECTNO>§ 26.202 </SECTNO>
                                <SUBJECT>[Reserved]</SUBJECT>
                            </SECTION>
                        </SUBPART>
                        <SUBPART>
                            <HD SOURCE="HED">Subpart D—Technical Standards.</HD>
                            <SECTION>
                                <SECTNO>§ 26.301 </SECTNO>
                                <SUBJECT>[Reserved]</SUBJECT>
                            </SECTION>
                            <SECTION>
                                <SECTNO>§ 26.302 </SECTNO>
                                <SUBJECT>Emission masks.</SUBJECT>
                                <P>
                                    (a) 
                                    <E T="03">2025-2110 MHz.</E>
                                     For frequencies offset from the assigned frequency less than the 50 percent of the necessary bandwidth, no attenuation is required. At a frequency offset equal to 50 percent of the necessary bandwidth, an attenuation of at least 8 dB is required. Frequencies offset more than 50 percent of the necessary bandwidth shall be attenuated by the following mask:
                                </P>
                                <HD SOURCE="HD3">Equation 1 to Paragraph (a)</HD>
                                <GPH SPAN="3" DEEP="31">
                                    <GID>ER05AU24.006</GID>
                                </GPH>
                                <EXTRACT>
                                    <FP SOURCE="FP-2">Where:</FP>
                                    <FP SOURCE="FP-2">
                                        f
                                        <E T="52">d</E>
                                         is the frequency displaced from the center of the emission bandwidth.
                                    </FP>
                                    <FP SOURCE="FP-2">
                                        B
                                        <E T="52">n</E>
                                         is the necessary bandwidth, which is determined in accordance with Annex J of the NTIA Manual of Regulations and Procedures for Federal Radio Frequency Management (NTIA Manual) (incorporated by reference, see § 26.305).
                                    </FP>
                                    <FP SOURCE="FP-2">dBsd is dB attenuation in a 4 kHz bandwidth, relative to the maximum power in any 4 kHz bandwidth within the necessary bandwidth (0 dBsd), where attenuation in this sense refers to the reduction in level relative to the reference, 0 dBsd, unless otherwise specified.</FP>
                                </EXTRACT>
                                <P>The unwanted emission mask rolls off at 40 dB per decade to a maximum attenuation of 60 dBsd, at which point it continues on both sides of the carrier for all frequencies beyond this point; see Annex M of the NTIA Manual regarding measurement requirements (incorporated by reference, see § 26.305); for any narrowband or single frequency unwanted emission which is not spread by the modulation process, the required attenuation shall be at least 60 dBc, where dBc is attenuation below the mean transmit power, rather than the dBsd value determined in equation 1 to this paragraph (a).</P>
                                <P>
                                    (b) 
                                    <E T="03">2200-2290 MHz.</E>
                                     (1) During the first stage of a launch, all spectral components larger than −[55 + 10xlog(P)] dBc (
                                    <E T="03">i.e.,</E>
                                     larger than −25 dBm) at the transmitter output must be within the spectral mask calculated using the following equation:
                                </P>
                                <HD SOURCE="HD3">Equation 2 to Paragraph (b)(1)</HD>
                                <FP SOURCE="FP-2">M(f) = K + 90 log(R)−100 log |f-fc|; |f-fc| ≥ R/m</FP>
                                <EXTRACT>
                                    <FP SOURCE="FP-2">Where: </FP>
                                    <FP SOURCE="FP-2">M(f) = power (dBc) at frequency f (MHz).</FP>
                                    <FP SOURCE="FP-2">K = −20 for analog signals.</FP>
                                    <FP SOURCE="FP-2">K = −28 for binary signals.</FP>
                                    <FP SOURCE="FP-2">K = −61 for FQPSK-B, FQPSK-JR, SOQPSK-TG.</FP>
                                    <FP SOURCE="FP-2">K = −73 for ARTM CPM.</FP>
                                    <FP SOURCE="FP-2">fc = transmitter center frequency (MHz).</FP>
                                    <FP SOURCE="FP-2">R = bit rate (Mbps) for digital signals or (Δf +fmax)(MHz) for analog FM signals.</FP>
                                    <FP SOURCE="FP-2">M = number of states in modulating signal (m = 2 for binary signals, m = 4 for quaternary signals and analog signals).</FP>
                                    <FP SOURCE="FP-2">f = peak deviation.</FP>
                                    <FP SOURCE="FP-2">fmax = maximum modulation frequency.</FP>
                                </EXTRACT>
                                <P>(2) After the first stage of a launch, the emission mask set forth in paragraph (a) of this section shall apply.</P>
                            </SECTION>
                            <SECTION>
                                <SECTNO>§ 26.303 </SECTNO>
                                <SUBJECT>Power limits.</SUBJECT>
                                <P>
                                    (a) 
                                    <E T="03">2025-2110 MHz.</E>
                                     The equivalent isotropically radiated power (EIRP) transmitted in any direction towards the horizon by an earth station in the 2025-2110 MHz band of the Space Launch Services shall not (with limited exceptions) exceed the following limits:
                                </P>
                                <P>
                                    (1) +40 dBW in any 4 kHz band for 
                                    <E T="8153">u</E>
                                     ≤0°;
                                </P>
                                <P>
                                    (2) +40+3
                                    <E T="8153">u</E>
                                     dBW in any 4 kHz band for 0°&lt; 
                                    <E T="8153">u</E>
                                     ≤5°; and
                                </P>
                                <P>
                                    (3) Where 
                                    <E T="8153">u</E>
                                     is the angle of elevation of the horizon viewed from the center of radiation of the antenna of the earth station and measured in degrees as positive above the horizontal plane and negative below it.
                                </P>
                                <P>
                                    (b) 
                                    <E T="03">2200-2290 MHz.</E>
                                     During the first stage of a launch, the EIRP of any station in the 2200-2290 MHz band of the Space Launch Services shall not exceed 25 Watts and the transmitter output power shall not exceed 25 Watts. In addition, the power flux-density at the Earth's surface produced by emissions from a transmitter operating after the first stage of a launch for all conditions and for all methods of modulation shall not exceed the following limits:
                                    <PRTPAGE P="63324"/>
                                </P>
                                <P>(1) −154 dB(W/m2) in any 4 kHz for angles of arrival less than 5° above the horizontal plane;</P>
                                <P>(2) −154 + 0.5 (δ−5) dB(W/m2) in any 4 kHz for angles of arrival δ (degrees) between 5° and 25° above the horizontal plane; and</P>
                                <P>(3) −144 dB(W/m2) in any 4 kHz for angles of arrival between 25° and 90° above the horizontal plane.</P>
                            </SECTION>
                            <SECTION>
                                <SECTNO>§ 26.304 </SECTNO>
                                <SUBJECT>Antenna structures; air navigation safety.</SUBJECT>
                                <P>A licensee that owns its antenna structure(s) must not allow such antenna structure(s) to become a hazard to air navigation. In general, antenna structure owners are responsible for registering antenna structures with the FCC if required by part 17 of this chapter, and for installing and maintaining any required marking and lighting. However, in the event of default of this responsibility by an antenna structure owner, the FCC permittee or licensee authorized to use an affected antenna structure will be held responsible by the FCC for ensuring that the antenna structure continues to meet the requirements of part 17. See § 17.6 of this chapter.</P>
                                <P>
                                    (a) 
                                    <E T="03">Marking and lighting.</E>
                                     Antenna structures must be marked, lighted and maintained in accordance with part 17 of this chapter and all applicable rules and requirements of the Federal Aviation Administration (see §§ 77.5 through 77.11 of this chapter). For any construction or alteration that would exceed the requirements of § 17.7 of this chapter, licensees must notify the appropriate Regional Office of the Federal Aviation Administration (FAA Form 7460-1) and file a request for antenna height clearance and obstruction marking and lighting specifications (FCC Form 854) with the FCC, WTB, 1270 Fairfield Road, Gettysburg, PA 17325.
                                </P>
                                <P>
                                    (b) 
                                    <E T="03">Maintenance contracts.</E>
                                     Antenna structure owners (or licensees and permittees, in the event of default by an antenna structure owner) may enter into contracts with other entities to monitor and carry out necessary maintenance of antenna structures. Antenna structure owners (or licensees and permittees, in the event of default by an antenna structure owner) that make such contractual arrangements continue to be responsible for the maintenance of antenna structures in regard to air navigation safety.
                                </P>
                            </SECTION>
                            <SECTION>
                                <SECTNO>§ 26.305 </SECTNO>
                                <SUBJECT>Incorporation by reference.</SUBJECT>
                                <P>
                                    Certain material is incorporated by reference into this subpart with the approval of the Director of the Federal Register under 5 U.S.C. 552(a) and 1 CFR part 51. All approved incorporation by reference (IBR) material is available for inspection at the Federal Communications Commission (FCC) and at the National Archives and Records Administration (NARA). Contact the FCC at the address indicated in § 0.401(a) of this chapter; phone: (202) 418-0270; email: 
                                    <E T="03">oetinfo@fcc.gov.</E>
                                     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 National Telecommunications and Information Administration (NTIA), Office of Spectrum Management, 1401 Constitution Avenue NW, Room 1087, Washington, DC 20230; phone (202) 482-1850; website: 
                                    <E T="03">www.ntia.gov/office/office-spectrum-management-osm:</E>
                                </P>
                                <P>
                                    (a) NTIA Manual of Regulations and Procedures for Federal Radio Frequency Management, Annex J: Guidance for Determination of Necessary Bandwidth, NTIA Manual of Regulations and Procedures for Federal Radio Frequency Management, January 2023 Revision (of the January 2021 Edition); IBR approved for § 26.302. (Available at 
                                    <E T="03">www.ntia.gov/sites/default/files/2023-11/j_2021_edition_rev_2023.pdf.</E>
                                    )
                                </P>
                                <P>
                                    (b) NTIA Manual of Regulations and Procedures for Federal Radio Frequency Management, Annex M: Measurement Methods, January 2023 Revision (of the January 2021 Edition); IBR approved for § 26.302. (Available at 
                                    <E T="03">www.ntia.gov/sites/default/files/2023-11/m_2021_edition_rev_2023.pdf.</E>
                                    )
                                </P>
                            </SECTION>
                        </SUBPART>
                    </PART>
                </REGTEXT>
                <REGTEXT TITLE="47" PART="26">
                    <AMDPAR>10. Delayed indefinitely, add § 26.106 to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 26.106 </SECTNO>
                        <SUBJECT>Submission and filing of applications.</SUBJECT>
                        <P>
                            (a) Applications for authorizations in the Space Launch Services must be filed in the Universal Licensing System (ULS) in accordance with part 1, subpart F, of this chapter. All modifications or renewals of licenses, assignments or transfers of control of licenses or any rights thereunder, and waiver requests associated with any of the foregoing shall be granted only upon an application filed pursuant to part 1, subpart F, as well. Applicants should also refer to the Commission rules regarding the payment of statutory charges (subpart G of part 1) and the use of the FCC Registration Number (FRN) (
                            <E T="03">see</E>
                             subpart W of part 1).
                        </P>
                        <P>(b) All applications and other filings using the application and notification forms listed in part 1, subpart F, of this chapter or associated schedules must be filed electronically in accordance with the electronic filing instructions provided by ULS. The Commission will announce by public notice the deployment date of the service in ULS and provide corresponding filing instructions.</P>
                    </SECTION>
                </REGTEXT>
                <REGTEXT TITLE="47" PART="26">
                    <AMDPAR>11. Delayed indefinitely, add § 26.108 to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 26.108 </SECTNO>
                        <SUBJECT>Content of applications; registration of stations.</SUBJECT>
                        <P>
                            (a) 
                            <E T="03">Application for authorization.</E>
                             Each application for authorization required by this part shall be specific and complete with regard to the information requested by the application forms in part 1, subpart F, of this chapter and associated public notice(s). Applicants must provide any additional information requested by the National Telecommunications and Information Administration (NTIA) or the frequency coordinator to complete the frequency coordination process set forth in subpart C of this part.
                        </P>
                        <P>
                            (b) 
                            <E T="03">Station registration.</E>
                             Once authorization is granted, Space Launch Services licensees must register in ULS each launch site and each corresponding station (fixed, base, itinerant, or mobile) that will be used in their space launch operations, as well as each individual launch that has completed the frequency coordination process set forth in subpart C of this part.
                        </P>
                        <P>
                            (c) 
                            <E T="03">Update of data.</E>
                             Space Launch Services licensees have a continuing obligation to update their licenses and corresponding site and station registration data as soon as the operational or technical details of a launch changes to ensure proper coordination.
                        </P>
                    </SECTION>
                </REGTEXT>
                <REGTEXT TITLE="47" PART="26">
                    <AMDPAR>12. Delayed indefinitely, add § 26.202 to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 26.202 </SECTNO>
                        <SUBJECT>Frequency coordinator requirements.</SUBJECT>
                        <P>Once an application for a new Space Launch Services authorization is granted, each Space Launch Services licensee must submit, for each proposed launch operation, the applicable launch site and corresponding fixed, base, itinerant, and mobile stations consistent with this subpart and submit their technical and operational parameters to the space launch frequency coordinator to initiate post-grant frequency coordination. Any changes to the technical and operational parameters for a launch event that occur after completion of post-grant frequency coordination also require coordination, and these changes shall be provided to initiate an updated post-frequency grant coordination.</P>
                        <P>
                            (a) The space launch frequency coordinator may request, and Space Launch Services licensees are required 
                            <PRTPAGE P="63325"/>
                            to provide, all appropriate technical information, system requirements, and justification for requested station parameters when such information is necessary to identify and recommend the most appropriate frequency.
                        </P>
                        <P>(b) In the 2025-2110 MHz band:</P>
                        <P>
                            (1) 
                            <E T="03">Site-based local coordination.</E>
                             (i) The space launch frequency coordinator must initiate a post-grant coordination request for site-specific coordination with the local Broadcast Auxiliary Service (BAS) frequency coordinator, including the provision of all necessary technical and operational parameters for each space launch licensee, to protect BAS, Cable Television Relay Service (CARS), and Local Television Transmission Service (LTTS) operations, as well as Federal entities that have completed coordination with the BAS frequency coordinator.
                        </P>
                        <P>(ii) The space launch frequency coordinator is not required to initiate a post-grant coordination request for site-specific coordination with the local BAS frequency coordinator if the Space Launch Services licensee provides a showing to the space launch frequency coordinator that:</P>
                        <P>(A) It has previously coordinated its proposed launch operations with the appropriate local BAS frequency coordinator and continues to comply with any conditions or agreements resulting from such prior coordination, or that it has entered into applicable coordination agreements with co-frequency entities;</P>
                        <P>(B) It has ascertained that its proposal will not constrain, preclude, nor interfere with incumbents in the band, including BAS, CARS, and LTTS licensees and previously coordinated Federal operations; and</P>
                        <P>(C) It has demonstrated in a technical showing that its proposed operation will not create more than 0.5 dB increase in the noise threshold of a receiver at a fixed or temporary fixed electronic news gathering (ENG) receive site.</P>
                        <P>(iii) Upon request, the space launch frequency coordinator and/or the Space Launch Services licensee must provide any additional information requested by the local BAS frequency coordinator regarding a pending recommendation that it has processed but has not yet been granted.</P>
                        <P>(iv) It is the responsibility of the space launch frequency coordinator to ensure that its frequency recommendations do not conflict with the frequency recommendations of the local BAS frequency coordinator. Should a conflict arise, the affected coordinators are jointly responsible for taking action to resolve the conflict, up to and including notifying the Commission and the National Telecommunications and Information Administration (NTIA) that a launch request must be denied.</P>
                        <P>
                            (2) 
                            <E T="03">Per-launch coordination with NTIA.</E>
                             (i) To protect Federal users in the band, the space launch frequency coordinator shall conduct a post-grant, per-launch coordination with NTIA by providing the Space Launch licensee's site and station registration with their corresponding technical and operational parameters to initiate the coordination process for each proposed launch.
                        </P>
                        <P>(ii) To assist NTIA's review, the space launch frequency coordinator may provide a showing that the operational and technical parameters of a proposed launch are consistent with a prior successful coordination and that the space launch licensee continues to comply with any conditions or agreements resulting from such prior coordination or that its proposed launch is covered by an applicable coordination agreement(s) with co-frequency entities.</P>
                        <P>(c) In the 2200-2290 MHz band:</P>
                        <P>
                            (1) 
                            <E T="03">Per-launch coordination with NTIA.</E>
                             (i) To protect Federal users in the band, the space launch frequency coordinator shall conduct a post-grant, per-launch coordination with NTIA by providing the Space Launch Services licensee's site and station registration with their corresponding technical and operational parameters to initiate the coordination process for each proposed launch.
                        </P>
                        <P>(ii) To assist NTIA's review, the space launch frequency coordinator may provide a showing that the operational and technical parameters of a proposed launch are consistent with a prior successful coordination and that the space launch licensee continues to comply with any conditions or agreements resulting from such prior coordination or that its proposed launch is covered by an applicable coordination agreement(s) with co-frequency entities.</P>
                        <P>(2) [Reserved]</P>
                    </SECTION>
                </REGTEXT>
                <REGTEXT TITLE="47" PART="26">
                    <AMDPAR>13. Delayed indefinitely, add § 26.301 to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 26.301 </SECTNO>
                        <SUBJECT>Authorized bandwidth.</SUBJECT>
                        <P>The Commission shall issue licenses in the Space Launch Services with bandwidths up to and including 5 megahertz, provided that the Commission may issue licenses with a maximum bandwidth exceeding 5 megahertz upon adequate justification from a license applicant explaining why the requested bandwidth is necessary for specific space launch operations, including an explanation of why the applicant's operations cannot be satisfied using a bandwidth of 5 megahertz or less.</P>
                    </SECTION>
                </REGTEXT>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-16638 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6712-01-P</BILCOD>
        </RULE>
        <RULE>
            <PREAMB>
                <AGENCY TYPE="N">GENERAL SERVICES ADMINISTRATION</AGENCY>
                <CFR>48 CFR Parts 501, 502, 538, and 552</CFR>
                <DEPDOC>[GSAR Case 2020-G510; Docket No. 2023-0025; Sequence No. 1]</DEPDOC>
                <RIN>RIN 3090-AK20</RIN>
                <SUBJECT>General Services Administration Acquisition Regulation; Federal Supply Schedule Economic Price Adjustment</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Office of Acquisition Policy, General Services Administration (GSA).</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Final rule.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The General Services Administration is amending the General Services Administration Acquisition Regulations (GSAR) to standardize and simplify the Multiple Award Schedule clauses for economic price adjustments. This rule removes certain economic price adjustment requirements within these clauses to better align with commercial standards and practices.</P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>This rule is effective on September 4, 2024.</P>
                </EFFDATE>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        For clarification of content, contact Mr. Thomas O'Linn, Procurement Analyst, at 
                        <E T="03">gsarpolicy@gsa.gov</E>
                         or 202-445-0390. For information pertaining to status or publication schedules, contact the Regulatory Secretariat at 
                        <E T="03">GSARegSec@gsa.gov</E>
                         or 202-501-4755. Please cite GSAR Case 2020-G510.
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">I. Background</HD>
                <P>This final rule amends the (GSAR) to standardize and simplify the Multiple Award Schedule (Schedule) clauses for economic price adjustments.</P>
                <P>
                    GSA published a proposed rule in the 
                    <E T="04">Federal Register</E>
                     at 88 FR 78710 on November 16, 2023. One respondent submitted comments in response to the proposed rule.
                </P>
                <HD SOURCE="HD1">II. Discussion and Analysis</HD>
                <P>GSA reviewed the public comments in the development of the final rule; however, no changes were made as a result of the public comments received. A discussion of the public comments received is provided as follows:</P>
                <HD SOURCE="HD2">A. Summary of Significant Changes</HD>
                <P>
                    There are no significant changes from the proposed rule.
                    <PRTPAGE P="63326"/>
                </P>
                <HD SOURCE="HD2">B. Analysis of Public Comments</HD>
                <HD SOURCE="HD3">1. Support for the Rule</HD>
                <P>
                    <E T="03">Comment:</E>
                     The respondent expressed support for the rule.
                </P>
                <P>
                    <E T="03">Response:</E>
                     GSA acknowledges the respondent's support for the rule.
                </P>
                <HD SOURCE="HD3">2. Training</HD>
                <P>
                    <E T="03">Comment:</E>
                     The respondent recommended contracting officers receive training on processing Schedule economic price adjustment (EPA) requests.
                </P>
                <P>
                    <E T="03">Response:</E>
                     GSA acknowledges the respondent's recommendation and will consider their recommendations as part of the training plan for this rule. GSA plans on reviewing and updating existing Schedule EPA training resources. GSA also intends to provide training to the acquisition workforce, including contracting officers.
                </P>
                <HD SOURCE="HD3">3. Guidance</HD>
                <P>
                    <E T="03">Comment:</E>
                     The respondent recommended guidance be revised and, if applicable, developed to support the processing of Schedule EPA requests.
                </P>
                <P>
                    <E T="03">Response:</E>
                     GSA acknowledges the respondent's recommendation and will consider their recommendations within the update of Schedule EPA guidance. GSA plans on updating existing Schedule EPA guidance to support the implementation of this rule. Guidance will include direction to contracting officers on how to properly process EPA requests based on the type of EPA mechanism (
                    <E T="03">e.g.,</E>
                     a fixed escalation rate and market indicator) identified in the contractor's Schedule contract.
                </P>
                <HD SOURCE="HD2">C. Summary of Minor Changes</HD>
                <P>1. General. The final rule renumbers the clause 552.238-118, Economic Price Adjustment—Federal Supply Schedule Contracts, to 552.238-120, Economic Price Adjustment—Federal Supply Schedule Contracts. The renumbering of this clause ensures consistency with the changes made to the GSAR that went into effect July 8, 2024 (see 89 FR 48330, June 6, 2024).</P>
                <P>2. Section 501.106, OMB Approval under the Paperwork Reduction Act. The final rule revises the entry for 552.238-120 to include Office of Management and Budget (OMB) Control No. 3090-0306. The revision is necessary to add all of the OMB information collections tied to this clause.</P>
                <P>3. Section 502.101, Definitions. The final rule revises the text for the definition of “Economic price adjustment (EPA) method” in order to add a parenthesis in front of the period.</P>
                <P>4. Section 538.273, FSS solicitation provisions and contract clauses. The final rule includes the redesignation of the clause 552.238-120, Economic Price Adjustment—Federal Supply Schedule Contracts, from paragraph (d)(38) to paragraph (d)(41). This change ensures the clauses listed in paragraph (d) of GSAR 538.273 remain in numerical order.</P>
                <P>5. Section 538.273, FSS solicitation provisions and contract clauses. The final rule includes the removal of the following “Use in Federal Supply Schedule solicitations and contracts.” The removal of this text ensures consistency with the changes made to this section, which went into effect February 12, 2024 (see 89 FR 2172, January 12, 2024).</P>
                <HD SOURCE="HD1">III. Expected Impact of the Rule</HD>
                <P>This rule will benefit the Schedule program as a whole. For example, GSA anticipates that these changes will increase the number and extent of offerings available through the Schedule program, improve customer satisfaction/reduce customer cost by ensuring needed products, services, and solutions are not removed from the Schedule program due to market volatility, and reduce administrative costs on Schedule contractors, particularly small businesses and new entrants.</P>
                <P>GSA receives hundreds of modification requests each month from contractors to remove items from their Schedule contracts or declined orders due to price variability in the commercial market. By statute, the procedures for the Schedule program are competitive so long as they are open to all and contracts and orders result in the lowest overall cost alternative. GSA anticipates this rule will help it ensure customers experience the lowest overall cost alternative on their orders by maximizing the chance that full solutions are available on the Schedule contract, thus minimizing the need to conduct multiple separate acquisitions to fulfill a requirement.</P>
                <P>Currently, Schedule contracts included at least one of the following four clauses related to the submission and processing of EPA requests during contract performance: (1) an authorized deviation to GSAR clause 552.216-70; (2) Alternate I of GSAR clause 552.216-70; (3) clause I-FSS-969; or (4) an Alternate of clause I-FSS-969. This rule standardizes and simplifies the EPA requirements contained in these four clauses. This rule consolidates these four clauses into a single Schedule EPA clause. These changes do not alter the way Schedule contractors conduct business, or their ability to submit an EPA request.</P>
                <P>The qualitative anticipated benefits include, but are not limited to, the creation of a single standardized Schedule EPA clause; greater flexibility around EPA requests; providing clarity around EPA within the Schedule program; providing a connection between the Schedule solicitation and resultant contracts; and greater flexibility and agility for purposes of responding to changing conditions.</P>
                <P>
                    GSA anticipates the quantitative benefits to be related to improved regulatory familiarization. GSA calculates the estimated total cost for Schedule contractors to familiarize themselves with existing EPA requirements as $3,251,640 (
                    <E T="03">i.e.,</E>
                     3 hours 
                    <SU>* </SU>
                     $77.42 
                    <SU>1</SU>
                    <FTREF/>
                     (GS-12 Step 5 base pay plus “Rest of US Locality Pay” plus “Fringe”) 
                    <SU>*</SU>
                     14,000 approximate number of current Schedule contractors)). After these revisions: GSA estimates the total cost as $2,709,700 (
                    <E T="03">i.e.,</E>
                     2.5 hours 
                    <SU>*</SU>
                     $77.42 (GS-12 Step 5 base pay plus “Rest of US Locality Pay” plus “Fringe”) 
                    <SU>*</SU>
                     14,000 approximate number of current Schedule contractors)). Resulting in a reduction in estimated total cost of $541,940.
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         2023 Rest of US, 12 Step 5 × 2.0 fringe = $77.42; the rate is adjusted upward by 100% to adjust for overhead and benefits.
                    </P>
                </FTNT>
                <HD SOURCE="HD1">IV. Executive Orders 12866, 13563, and 14094</HD>
                <P>
                    Executive Order (E.O.) 12866 (Regulatory Planning and Review) directs agencies to assess all costs and benefits of available regulatory alternatives and, if regulation is necessary, to select regulatory approaches that maximize net benefits (including potential economic, environmental, public health and safety effects, distributive impacts, and equity). E.O. 13563 (Improving Regulation and Regulatory Review) emphasizes the importance of quantifying both costs and benefits, of reducing costs, of harmonizing rules, and of promoting flexibility. E.O. 14094 (Modernizing Regulatory Review) supplements and reaffirms the principles, structures, and definitions governing contemporary regulatory review established in E.O. 12866 and E.O. 13563. The Office of Information and Regulatory Affairs (OIRA) has determined that this rule is not a significant regulatory action, and, therefore, is not subject to review under section 6(b) of E.O. 12866, Regulatory Planning and Review, dated September 30, 1993.
                    <PRTPAGE P="63327"/>
                </P>
                <HD SOURCE="HD1">V. Congressional Review Act</HD>
                <P>
                    OIRA has determined that this rule is not a major rule under 5 U.S.C. 804(2). Subtitle E of the Small Business Regulatory Enforcement Fairness Act of 1996 (codified at 5 U.S.C. 801-808), also known as the Congressional Review Act or CRA, generally provides that before a “major rule” may take effect, the agency promulgating the rule must submit a rule report, which includes a copy of the rule, to each House of the Congress and to the Comptroller General of the United States. The General Services Administration will submit a report containing this rule and other required information to the U.S. Senate, the U.S. House of Representatives, and the Comptroller General of the United States. A major rule under the CRA cannot take effect until 60 days after it is published in the 
                    <E T="04">Federal Register</E>
                    .
                </P>
                <HD SOURCE="HD1">VI. Regulatory Flexibility Act</HD>
                <P>
                    GSA does not expect this final rule 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, 
                    <E T="03">et seq.,</E>
                     because this rule is to standardize and simplify existing EPA requirements related to Schedule (
                    <E T="03">e.g.,</E>
                     revise GSAR clause 552.216-70, Economic Price Adjustment-FSS Multiple Award Schedule Contracts).
                </P>
                <P>
                    The underlying purpose of the changed text remains the same (
                    <E T="03">i.e.,</E>
                     supporting the submission and processing of EPA requests), and therefore any burden would have been identified previously.
                </P>
                <P>
                    There were no significant issues raised by the public comments in response to the initial regulatory flexibility analysis. A Final Regulatory Flexibility Analysis (FRFA) has been prepared consistent with 5 U.S.C. 603 
                    <E T="03">et seq.</E>
                     The FRFA is summarized as follows:
                </P>
                <EXTRACT>
                    <P>The objective of the rule is to standardize and simplify the clauses for Schedules related to EPA. These revisions consolidate the four existing Schedule clauses into a single Schedule EPA clause. These revisions also remove certain procedural limits contained in these clauses to better align with commercial standards and practices. GSA anticipates that these changes will increase the number and extent of offerings available through the Schedule program, improve customer satisfaction/reduce customer costs by ensuring needed products, services, and solutions are not removed from the Schedule program, and reduce administrative costs on Schedule contractors, particularly small businesses and new entrants.</P>
                    <P>Title 40 of the United States Code (U.S.C.) section 121 authorizes GSA to issue regulations, including the GSAR, to control the relationship between GSA and contractors. In addition, 41 U.S.C. 152 provides GSA authority over the Schedule program.</P>
                    <P>The rule applies to both large and small businesses, which are awarded Schedule contracts. Information obtained from FAS as well as the recent renewal of Information Collections 3090-0235 and 3090-0306 were used as the basis for estimating the number of Schedule contractors that this rule may impact. For Fiscal Year 2023 there were approximately 14,000 Schedule contractors, of which over 12,000 (85 percent) were small business entities. In addition, according to the recent renewal of Information Collections 3090-0235 and 3090-0306, GSA processes approximately 2,561 EPA requests annually. GSA anticipates this rule will not significantly impact this number.</P>
                    <P>The rule does not implement new or changed reporting, recordkeeping, or other compliance requirements for Schedule contracts. The rule merely updates and clarifies existing EPA requirements currently used in Schedule contracts.</P>
                    <P>The rule does not duplicate, overlap, or conflict with any other Federal rules.</P>
                    <P>There are no known alternatives to this rule which would accomplish the stated objectives. This rule does not initiate or impose any new administrative or performance requirements on small business contractors because the requirements prescribed in existing Schedule EPA clauses are already being followed. The rule merely updates and clarifies these existing requirements so as to reduce burden for both the government and contractors as it relates to EPA within Schedule contracts.</P>
                </EXTRACT>
                <P>Interested parties may obtain a copy of the FRFA from the Regulatory Secretariat Division. The Regulatory Secretariat Division has submitted a copy of the FRFA to the Chief Counsel for Advocacy of the Small Business Administration.</P>
                <HD SOURCE="HD1">VII. Paperwork Reduction Act</HD>
                <P>The Paperwork Reduction Act (44 U.S.C. chapter 3501) does apply; however, these changes do not impose additional information collection requirements to the burden previously approved under OMB Control Number 3090-0235, titled: Federal Supply Schedule Pricing Disclosures and Sales Reporting and OMB Control Number 3090-0306, titled: Transactional Data Reporting. Both OMB information collections, however, will be updated to reflect the change in the clause title and number from 552.216-70, Economic Price Adjustment—FSS Multiple Award Schedule Contracts, to 552.238-120, Economic Price Adjustment—Federal Supply Schedule Contracts.</P>
                <LSTSUB>
                    <HD SOURCE="HED">List of Subjects in 48 CFR Parts 501, 502, 538, and 552</HD>
                    <P>Government procurement.</P>
                </LSTSUB>
                <SIG>
                    <NAME>Jeffrey A. Koses,</NAME>
                    <TITLE>Senior Procurement Executive, Office of Acquisition Policy, Office of Government-Wide Policy, General Services Administration.</TITLE>
                </SIG>
                  
                <P>Therefore, GSA amends 48 CFR parts 501, 502, 538, and 552 as set forth below:</P>
                <REGTEXT TITLE="48" PART="501">
                    <AMDPAR>1. The authority citation for 48 CFR parts 501, 502, 538, and 552 continues to read as follows:</AMDPAR>
                    <AUTH>
                        <HD SOURCE="HED">Authority:</HD>
                        <P> 40 U.S.C. 121(c).</P>
                    </AUTH>
                </REGTEXT>
                <PART>
                    <HD SOURCE="HED">PART 501—GENERAL SERVICES ADMINISTRATION ACQUISITION REGULATION SYSTEM</HD>
                </PART>
                <REGTEXT TITLE="48" PART="501">
                    <AMDPAR>2. In section 501.106, amend table 1 by—</AMDPAR>
                    <AMDPAR>a. Revising the entry for “516.506”;</AMDPAR>
                    <AMDPAR>b. Removing the entry for “552.216-70”; and</AMDPAR>
                    <AMDPAR>c. Adding, in numerical order, entries for “552.238-83” and “552.238-120”.</AMDPAR>
                    <P>The revision and additions read as follows:</P>
                    <SECTION>
                        <SECTNO>501.106</SECTNO>
                        <SUBJECT> OMB approval under the Paperwork Reduction Act.</SUBJECT>
                        <STARS/>
                        <GPOTABLE COLS="2" OPTS="L1,i1" CDEF="s35,r50">
                            <TTITLE>Table 1 to 501.106</TTITLE>
                            <BOXHD>
                                <CHED H="1">GSAR reference</CHED>
                                <CHED H="1">OMB control No.</CHED>
                            </BOXHD>
                            <ROW>
                                <ENT I="22"> </ENT>
                            </ROW>
                            <ROW>
                                <ENT I="28">*    *    *    *    *</ENT>
                            </ROW>
                            <ROW>
                                <ENT I="01">516.506</ENT>
                                <ENT>3090-0248, 3090-0306</ENT>
                            </ROW>
                            <ROW>
                                <ENT I="22"> </ENT>
                            </ROW>
                            <ROW>
                                <ENT I="28">*    *    *    *    *</ENT>
                            </ROW>
                            <ROW>
                                <ENT I="01">552.238-83</ENT>
                                <ENT>3090-0235, 3090-0306</ENT>
                            </ROW>
                            <ROW>
                                <ENT I="22"> </ENT>
                            </ROW>
                            <ROW>
                                <ENT I="28">*    *    *    *    *</ENT>
                            </ROW>
                            <ROW>
                                <ENT I="01">552.238-120</ENT>
                                <ENT>3090-0235, 3090-0306</ENT>
                            </ROW>
                            <ROW>
                                <ENT I="22"> </ENT>
                            </ROW>
                            <ROW>
                                <ENT I="28">*    *    *    *    *</ENT>
                            </ROW>
                        </GPOTABLE>
                    </SECTION>
                </REGTEXT>
                <PART>
                    <HD SOURCE="HED">PART 502—DEFINITIONS OF WORDS AND TERMS</HD>
                </PART>
                <REGTEXT TITLE="48" PART="502">
                    <AMDPAR>3. Amend section 502.101 by adding, in alphabetical order, the definition of “Economic price adjustment (EPA) method” to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>502.101</SECTNO>
                        <SUBJECT> Definitions.</SUBJECT>
                        <STARS/>
                        <P>
                            <E T="03">Economic price adjustment (EPA) method</E>
                             means the agreed upon procedure by which pricing may be adjusted throughout the contract period to include, but not limited to, the mechanism(s) to be used to adjust pricing (
                            <E T="03">e.g.,</E>
                             adjustments based on established pricing), the pricing subject to adjustment, and any other 
                            <PRTPAGE P="63328"/>
                            requirements (
                            <E T="03">e.g.,</E>
                             timing, frequency, limits on increases).
                        </P>
                        <STARS/>
                    </SECTION>
                </REGTEXT>
                <PART>
                    <HD SOURCE="HED">PART 538—FEDERAL SUPPLY SCHEDULE CONTRACTING</HD>
                </PART>
                <REGTEXT TITLE="48" PART="538">
                    <AMDPAR>4. Amend section 538.273 by adding paragraph (d)(41) to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>538.273</SECTNO>
                        <SUBJECT> FSS solicitation provisions and contract clauses.</SUBJECT>
                        <STARS/>
                        <P>(d) * * *</P>
                        <P>(41) 552.238-120, Economic Price Adjustment—Federal Supply Schedule Contracts.</P>
                        <STARS/>
                    </SECTION>
                </REGTEXT>
                <PART>
                    <HD SOURCE="HED">PART 552—SOLICITATION PROVISIONS AND CONTRACT CLAUSES</HD>
                    <SECTION>
                        <SECTNO>552.216-70</SECTNO>
                        <SUBJECT> [Removed]</SUBJECT>
                    </SECTION>
                </PART>
                <REGTEXT TITLE="48" PART="552">
                    <AMDPAR>5. Remove section 552.216-70.</AMDPAR>
                    <AMDPAR>6. Amend section 552.238-115 by:</AMDPAR>
                    <AMDPAR>a. Revising the date of the clause;</AMDPAR>
                    <AMDPAR>b. Removing paragraph (d)(10)(i);</AMDPAR>
                    <AMDPAR>c. Redesignating paragraphs (d)(10)(ii) and (iii) as paragraphs (d)(10)(i) and (ii); and</AMDPAR>
                    <AMDPAR>d. Adding new paragraph (d)(10)(iii).</AMDPAR>
                    <P>The revision and addition read as follows:</P>
                    <SECTION>
                        <SECTNO>552.238-115</SECTNO>
                        <SUBJECT> Special Ordering Procedures for the Acquisition of Order-Level Materials.</SUBJECT>
                        <STARS/>
                        <HD SOURCE="HD1">Special Ordering Procedures for the Acquisition of Order-Level Materials (DATE)</HD>
                        <STARS/>
                        <P>(d) * * *</P>
                        <P>(10) * * *</P>
                        <P>(iii) 552.238-120, Economic Price Adjustment—Federal Supply Schedule Contracts.</P>
                        <STARS/>
                    </SECTION>
                </REGTEXT>
                <REGTEXT TITLE="48" PART="552">
                    <AMDPAR>7. Add section 552.238-120 to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>552.238-120</SECTNO>
                        <SUBJECT> Economic Price Adjustment—Federal Supply Schedule Contracts.</SUBJECT>
                        <P>As prescribed in 538.273(d), insert the following clause:</P>
                        <HD SOURCE="HD1">552.238-120 Economic Price Adjustment—Federal Supply Schedule Contracts (DATE)</HD>
                        <P>
                            (a) 
                            <E T="03">Definition.</E>
                        </P>
                        <P>
                            <E T="03">Economic price adjustment method,</E>
                             as used in this clause, means the agreed upon procedures by which pricing may be adjusted throughout the contract period to include, but not limited to, the mechanism(s) to be used to adjust pricing (
                            <E T="03">e.g.,</E>
                             adjustments based on established pricing), the pricing subject to adjustment, and any other requirements (
                            <E T="03">e.g.,</E>
                             timing, frequency, limits on increases).
                        </P>
                        <P>
                            (b) 
                            <E T="03">General.</E>
                             This contract provides for economic price adjustment (EPA) to contract pricing based on the established EPA method. EPA provides for the increase and decrease to stated contract pricing upon the occurrence of specified conditions described in the EPA method, such as market index changes or unforeseeable significant changes in market conditions.
                        </P>
                        <P>
                            (c) 
                            <E T="03">Exceptions.</E>
                             This clause does not cover—
                        </P>
                        <P>
                            (1) Adjustments based on statute, Executive Order, or regulation (
                            <E T="03">e.g.,</E>
                             Service Contract Labor Standards (41 U.S.C. chapter 67) and AbilityOne procurements (FAR subpart 8.7));
                        </P>
                        <P>
                            (2) Adjustments based on a change clause (
                            <E T="03">e.g.,</E>
                             paragraph (c) of GSAR clause 552.212-4, Contract Terms and Conditions—Commercial Products and Commercial Services (FAR DEVIATION 52.212-4));
                        </P>
                        <P>(3) Price reductions made under GSAR clause 552.238-81, Price Reductions;</P>
                        <P>(4) Adjustments based on GSAR clause 552.238-117, Price Adjustment-Failure to Provide Accurate Information; and</P>
                        <P>(5) Adjustments based on a contract clause that authorizes an adjustment based on specified actions or conditions.</P>
                        <P>
                            (d) 
                            <E T="03">Economic price adjustment method.</E>
                             The EPA method may be revised through mutual agreement of the parties. In the event of a conflict between the EPA method and this contract, the contract shall control.
                        </P>
                        <P>
                            (e) 
                            <E T="03">Submission requirements.</E>
                             The Contractor shall submit EPA requests to the Federal Supply Schedule (FSS) Contracting Officer pursuant to the EPA method. EPA requests shall fully conform to the requirements of the EPA method and include sufficient information to support the request. The FSS Contracting Officer may request additional information from the Contractor.
                        </P>
                        <P>
                            (f) 
                            <E T="03">Contracting Officer responsibilities.</E>
                             The FSS Contracting Officer will—
                        </P>
                        <P>(1) Review the EPA request to ensure conformance with the EPA method,</P>
                        <P>
                            (2) Make a determination. The FSS Contracting Officer may use any information (
                            <E T="03">e.g.,</E>
                             market research) deemed necessary to support their determination. The FSS Contracting Officer may determine to—
                        </P>
                        <P>(i) Accept the EPA request either in whole or in part,</P>
                        <P>(ii) Reject the EPA request either in whole or in part, or</P>
                        <P>
                            (iii) Take any other action deemed to be in the best interest of the Government (
                            <E T="03">e.g.,</E>
                             negotiate a more favorable EPA).
                        </P>
                        <P>(3) Notify the Contractor of their determination, and</P>
                        <P>(4) Modify the contract, as applicable, to reflect the determination. Contract items that need to be removed from the contract as a result of rejection or an inability to reach agreement are to be removed in accordance with 552.238-79, Cancellation.</P>
                        <P>
                            (g) 
                            <E T="03">Effective date.</E>
                             EPA requests approved by the FSS Contracting Officer under this clause shall apply to orders issued on or after the effective date of the contract modification. Blanket Purchase Agreements (BPAs) may be modified by the ordering agency in accordance with the terms and conditions of the BPA.
                        </P>
                        <P>
                            (h) 
                            <E T="03">Update of contract pricing and catalog data.</E>
                             The Contractor shall update its FSS pricing and any other FSS catalog data in accordance with the terms and conditions of this contract.
                        </P>
                        <HD SOURCE="HD3">(End of clause)</HD>
                    </SECTION>
                </REGTEXT>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-16980 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6820-61-P</BILCOD>
        </RULE>
    </RULES>
    <VOL>89</VOL>
    <NO>150</NO>
    <DATE>Monday, August 5, 2024</DATE>
    <UNITNAME>Proposed Rules</UNITNAME>
    <PRORULES>
        <PRORULE>
            <PREAMB>
                <PRTPAGE P="63329"/>
                <AGENCY TYPE="F">DEPARTMENT OF TRANSPORTATION</AGENCY>
                <SUBAGY>Federal Aviation Administration</SUBAGY>
                <CFR>14 CFR Part 71</CFR>
                <DEPDOC>[Docket No. FAA-2023-2176; Airspace Docket No. 23-ASO-47]</DEPDOC>
                <RIN>RIN 2120-AA66</RIN>
                <SUBJECT>Amendment of Class D and Class E Airspace; Gainesville, FL</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>This action proposes to amend Class E airspace extending upward from 700 feet above the surface for Gainesville Regional Airport, Gainesville, FL, as new instrument approach procedures have been designed for Shands Cair Heliport and Shands Helistop Heliport, Gainesville, FL. This action would also replace the terms Notice to Airmen with Notice to Air Missions and Airport/Facility Directory with Chart Supplement in the Class D and Class E descriptions.</P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Comments must be received on or before September 19, 2024.</P>
                </EFFDATE>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>Send comments identified by FAA Docket No. FAA-2023-2176 and Airspace Docket No. 23-ASO-47 using any of the following methods:</P>
                    <P>
                        * 
                        <E T="03">Federal eRulemaking Portal:</E>
                         Go to 
                        <E T="03">www.regulations.gov</E>
                         and follow the online instructions for sending your comments electronically.
                    </P>
                    <P>
                        * 
                        <E T="03">Mail:</E>
                         Send comments to Docket Operations, M-30; U.S. Department of Transportation, 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 for Federal holidays.
                    </P>
                    <P>
                        * 
                        <E T="03">Fax:</E>
                         Fax comments to Docket Operations at (202) 493-2251.
                    </P>
                    <P>
                        <E T="03">Docket:</E>
                         Background documents or comments received may be read at 
                        <E T="03">www.regulations.gov</E>
                         at any time. Follow the online instructions for accessing the docket or go to the Docket Operations in Room W12-140 of the West Building Ground Floor at 1200 New Jersey Avenue SE, Washington, DC, between 9 a.m. and 5 p.m., Monday through Friday, except for Federal holidays.
                    </P>
                    <P>
                        FAA Order JO 7400.11H Airspace Designations and Reporting Points, and subsequent amendments can be viewed online at 
                        <E T="03">www.faa.gov/air_traffic/publications/.</E>
                         You may also contact the Rules and Regulations Group, Office of Policy, Federal Aviation Administration, 800 Independence Avenue SW, Washington, DC 20591; telephone: (202) 267-8783.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Scott Stuart, Operations Support Group, Eastern Service Center, Federal Aviation Administration, 1701 Columbia Avenue, College Park, GA 30337; telephone: (404) 305-5926.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">Authority for This Rulemaking</HD>
                <P>The FAA's authority to issue rules regarding aviation safety is found in Title 49 of the United States Code. Subtitle I, Section 106 describes the authority of the FAA Administrator. Subtitle VII, Aviation Programs, describes in more detail the scope of the agency's authority. This rulemaking is promulgated under the authority described in Subtitle VII, Part A, Subpart I, Section 40103. Under that section, the FAA is charged with prescribing regulations to assign the use of airspace necessary to ensure the safety of aircraft and the efficient use of airspace. This regulation is within the scope of that authority, as it would amend Class E airspace at Gainesville Regional Airport, Gainesville, FL.</P>
                <HD SOURCE="HD1">Comments Invited</HD>
                <P>The FAA invites interested persons to participate in this rulemaking by submitting written comments, data, or views. Comments are specifically invited on the overall regulatory, aeronautical, economic, environmental, and energy-related aspects of the proposal. The most helpful comments reference a specific portion of the proposal, explain the reason for any recommended change, and include supporting data. To ensure the docket does not contain duplicate comments, commenters should submit only one time if comments are filed electronically, or commenters should send only one copy of written comments if comments are filed in writing.</P>
                <P>The FAA will file in the docket all comments it receives, as well as a report summarizing each substantive public contact with FAA personnel concerning this proposed rulemaking. Before acting on this proposal, the FAA will consider all comments it receives on or before the closing date for comments. The FAA will consider comments filed after the comment period has closed if it is possible to do so without incurring expense or delay. The FAA may change this proposal in light of the comments it receives.</P>
                <P>
                    <E T="03">Privacy:</E>
                     In accordance with 5 U.S.C. 553(c), DOT solicits comments from the public to better inform its rulemaking process. DOT posts these comments, without edit, including any personal information the commenter provides, to 
                    <E T="03">www.regulations.gov,</E>
                     as described in the system of records notice (DOT/ALL-14 FDMS), which can be reviewed at 
                    <E T="03">www.dot.gov/privacy.</E>
                </P>
                <HD SOURCE="HD1">Availability of Rulemaking Documents</HD>
                <P>
                    An electronic copy of this document may be downloaded through the internet at 
                    <E T="03">www.regulations.gov.</E>
                     Recently published rulemaking documents can also be accessed through the FAA's web page at 
                    <E T="03">www.faa.gov/air_traffic/publications/airspace_amendments/.</E>
                </P>
                <P>
                    You may review the public docket containing the proposal, any comments received, and any final disposition in person in the Dockets Operations office (see 
                    <E T="02">ADDRESSES</E>
                     section for address, phone number, and hours of operations). An informal docket may also be examined during regular business hours at the office of the Eastern Service Center, Federal Aviation Administration, Room 210, 1701 Columbia Ave., College Park, GA 30337.
                </P>
                <HD SOURCE="HD1">Incorporation by Reference</HD>
                <P>
                    Class D and Class E airspace are published in paragraphs 5000, 6002, and 6005 of FAA Order JO 7400.11, Airspace Designations and Reporting Points, which is incorporated by 
                    <PRTPAGE P="63330"/>
                    reference in 14 CFR 71.1 on an annual basis. This document proposes to amend the current version of that order, FAA Order JO 7400.11H, dated August 11, 2023, and effective September 15, 2023. FAA Order JO 7400.11H is publicly available as listed in the 
                    <E T="02">ADDRESSES</E>
                     section of this document. These amendments will be published in the next update to FAA Order JO 7400.11.
                </P>
                <P>FAA Order JO 7400.11H lists Class A, B, C, D, and E airspace areas, air traffic service routes, and reporting points.</P>
                <HD SOURCE="HD1">The Proposal</HD>
                <P>This action proposes to amend 14 CFR part 71 by amending Class E airspace extending upward from 700 feet above the surface for Gainesville Regional Airport, Gainesville, FL, by increasing the airspace within a 7-mile radius (previously 6 miles) of Shands Cair Heliport, FL serving multiple heliports. Additionally, this action would also delete the Point In Space Coordinates for Shands Hospital and use Shands Cair Heliport as a reference to accommodate both hospital's Class E airspace requirements. Also, this action would replace the terms Notice to Airmen with Notice to Air Missions and Airport/Facility Directory with Chart Supplement in the Class D and Class E descriptions. Controlled airspace is necessary for the safety and management of instrument flight rules (IFR) operations in the area.</P>
                <HD SOURCE="HD1">Regulatory Notices and Analyses</HD>
                <P>The FAA has determined that this regulation only involves an established body of technical regulations for which frequent and routine amendments are necessary to keep them operationally current. It, therefore: (1) is not a “significant regulatory action” under Executive Order 12866; (2) is not a “significant rule” under DOT Regulatory Policies and Procedures (44 FR 11034; February 26, 1979); and (3) does not warrant preparation of a Regulatory Evaluation as the anticipated impact is so minimal. Since this is a routine matter that will only affect air traffic procedures and air navigation, it is certified that this proposed rule, when promulgated, will not have a significant economic impact on a substantial number of small entities under the criteria of the Regulatory Flexibility Act.</P>
                <HD SOURCE="HD1">Environmental Review</HD>
                <P>This proposal would be subject to an environmental analysis in accordance with FAA Order 1050.1F, “Environmental Impacts: Policies and Procedures,” prior to any FAA final regulatory action.</P>
                <LSTSUB>
                    <HD SOURCE="HED">Lists of Subjects in 14 CFR Part 71</HD>
                    <P>Airspace, Incorporation by reference, Navigation (air).</P>
                </LSTSUB>
                <HD SOURCE="HD1">The Proposed Amendment</HD>
                <P>In consideration of the foregoing, the Federal Aviation Administration proposes to amend 14 CFR part 71 as follows:</P>
                <PART>
                    <HD SOURCE="HED">PART 71—DESIGNATION OF CLASS A, B, C, D, AND E AIRSPACE AREAS; AIR TRAFFIC SERVICE ROUTES; AND REPORTING POINTS</HD>
                </PART>
                <AMDPAR>1. The authority citation for 14 CFR part 71 continues to read as follows:</AMDPAR>
                <AUTH>
                    <HD SOURCE="HED">Authority:</HD>
                    <P> 49 U.S.C. 106(f), 106(g); 40103, 40113, 40120; E.O. 10854, 24 FR 9565, 3 CFR, 1959-1963 Comp., p. 389.</P>
                </AUTH>
                <SECTION>
                    <SECTNO>§ 71.1</SECTNO>
                    <SUBJECT>[Amended]</SUBJECT>
                </SECTION>
                <AMDPAR>2. The incorporation by reference in 14 CFR 71.1 of Federal Aviation Administration Order JO 7400.11H, Airspace Designations and Reporting Points, dated August 11, 2023, and effective September 15, 2023, is amended as follows:</AMDPAR>
                <EXTRACT>
                    <HD SOURCE="HD2">Paragraph 5000 Class D Airspace.</HD>
                    <STARS/>
                    <HD SOURCE="HD1">ASO FL D Gainesville, FL [AMENDED]</HD>
                    <FP SOURCE="FP-2">Gainesville Regional Airport, FL</FP>
                    <FP SOURCE="FP1-2">(Lat. 29°41′24″ N, long. 82°16′18″ W)</FP>
                    <P>That airspace extending upward from the surface to and including 2,700 feet MSL within a 4.9-mile radius of the Gainesville Regional Airport. This Class D airspace area is effective during the specific dates and times established in advance by a Notice to Air Missions. The effective date and time will thereafter be continuously published in the Chart Supplement.</P>
                    <STARS/>
                    <HD SOURCE="HD2">Paragraph 6002 Class E Surface Airspace.</HD>
                    <STARS/>
                    <HD SOURCE="HD1">ASO FL E2 Gainesville, FL [AMENDED]</HD>
                    <FP SOURCE="FP-2">Gainesville Regional Airport, FL</FP>
                    <P>(Lat. 29°41′24″ N, long. 82°16′18″ W)</P>
                    <P>Within a 4.9-mile radius of the Gainesville Regional Airport. This Class E airspace area is effective during the specific dates and times established in advance by a Notice to Air Missions. The effective date and time will thereafter be continuously published in the Chart Supplement.</P>
                    <STARS/>
                    <HD SOURCE="HD2">Paragraph 6005 Class E Surface Airspace.</HD>
                    <STARS/>
                    <HD SOURCE="HD1">ASO FL E5 Gainesville, FL [AMENDED]</HD>
                    <FP SOURCE="FP-2">Gainesville Regional Airport, FL</FP>
                    <FP SOURCE="FP1-2">(Lat. 29°41′24″ N, long. 82°16′18″ W)</FP>
                    <FP SOURCE="FP-2">Shands Cair Heliport, FL</FP>
                    <FP SOURCE="FP1-2">(Lat. 29°38′08″ N, long. 82°21′02″ W)</FP>
                    <P>That airspace extending upward from 700 feet above the surface within a 7-mile radius of Gainesville Regional Airport and that airspace within a 7-mile radius of Shands Cair Heliport serving multiple heliports.</P>
                    <STARS/>
                </EXTRACT>
                <SIG>
                    <DATED>Issued in College Park, Georgia, on July 29, 2024.</DATED>
                    <NAME>Andreese C. Davis,</NAME>
                    <TITLE>Manager, Airspace &amp; Procedures Team South, Eastern Service Center, Air Traffic Organization.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17179 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4910-13-P</BILCOD>
        </PRORULE>
        <PRORULE>
            <PREAMB>
                <AGENCY TYPE="N">DEPARTMENT OF HEALTH AND HUMAN SERVICES</AGENCY>
                <SUBAGY>Food and Drug Administration</SUBAGY>
                <CFR>21 CFR Part 73</CFR>
                <DEPDOC>[Docket No. FDA-2024-C-3384]</DEPDOC>
                <SUBJECT>GNT USA, LLC; Filing of Color Additive Petition</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Food and Drug Administration, HHS.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notification of petition.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Food and Drug Administration (FDA or we) is announcing that we have filed a petition, submitted by GNT USA, LLC, proposing that the color additive regulations be amended to provide for the safe use of spirulina extract in foods generally in amounts consistent with good manufacturing practice.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>The color additive petition was filed on July 18, 2024. Either electronic or written comments on the petitioner's environmental assessment must be submitted by October 4, 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 October 4, 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 
                    <PRTPAGE P="63331"/>
                    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-2024-C-3384 for “GNT USA, LLC; Filing of Color Additive Petition.” 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.” We will review this copy, including the claimed confidential information, in our 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>Marissa Santos, Center for Food Safety and Applied Nutrition, Food and Drug Administration, 5001 Campus Dr., College Park, MD 20740, 240-402-8160.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    Under section 721(d)(1) of the Federal Food, Drug, and Cosmetic Act (21 U.S.C. 379e(d)(1)), we are giving notice that we have filed a color additive petition (CAP No. 4C0334), submitted on behalf of GNT USA, LLC by Exponent, Inc., 1150 Connecticut Ave. NW, Suite 1100, Washington, DC 20036. The petition proposes to amend the color additive regulations in part 73 (21 CFR part 73), 
                    <E T="03">Listing of Color Additives Exempt From Certification,</E>
                     to provide for the safe use of spirulina extract in foods generally in amounts consistent with good manufacturing practice.
                </P>
                <P>The petitioner has claimed that this action is categorically excluded under 21 CFR 25.32(k) because the substance is intended to be added directly to food, remain in food through ingestion by consumers, and is not intended to replace macronutrients in food. In addition, the petitioner has stated that, to their knowledge, no extraordinary circumstances exist. If FDA determines a categorical exclusion applies, neither an environmental assessment nor an environmental impact statement is required. If FDA determines a categorical exclusion does not apply, we will request an environmental assessment and make it available for public inspection.</P>
                <SIG>
                    <DATED>Dated: July 30, 2024.</DATED>
                    <NAME>Lauren K. Roth,</NAME>
                    <TITLE>Associate Commissioner for Policy.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17090 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4164-01-P</BILCOD>
        </PRORULE>
        <PRORULE>
            <PREAMB>
                <AGENCY TYPE="N">DEPARTMENT OF HOMELAND SECURITY</AGENCY>
                <SUBAGY>Coast Guard</SUBAGY>
                <CFR>33 CFR Part 165</CFR>
                <DEPDOC>[Docket Number USCG-2024-0503]</DEPDOC>
                <RIN>RIN 1625-AA00</RIN>
                <SUBJECT>Safety Zone; Upper Galveston Bay, Kemah, TX</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Coast Guard, DHS.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of proposed rulemaking.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Coast Guard is proposing to update the location and description of a safety zone, and add two annually recurring dates, for events at the Kemah Board Walk Fireworks Display, in the Upper Galveston Bay in Kemah, Texas. The safety zone is needed to protect personnel, vessels, and the marine environment from potential hazards created by the fireworks show. Entry of vessels or persons into this zone is prohibited unless specifically authorized by the Captain of the Port, Sector Houston-Galveston, or a designated representative. The purpose of this safety zone is to ensure no members of the public will be within the fallout radius from the fireworks show taking place, this will reduce the probability of any injuries or damage due to the inherent danger of launching fireworks from a barge. We invite your comments on this proposed rulemaking. </P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Comments and related material must be received by the Coast Guard on or before August 20, 2024.</P>
                </EFFDATE>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        You may submit comments identified by docket number USCG-2024-0503 using the Federal Decision-Making Portal at 
                        <E T="03">https://www.regulations.gov.</E>
                         See the “Public Participation and Request for Comments” portion of the 
                        <E T="02">SUPPLEMENTARY INFORMATION</E>
                         section for further instructions on submitting comments. This notice of proposed rulemaking with its plain-language, 100-word-or-less proposed rule summary will be available in this same docket.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        If you have questions about this proposed rulemaking, call or email Marine Science Technician First Class Christopher C. Morgan, Sector Houston-Galveston Waterways Management 
                        <PRTPAGE P="63332"/>
                        Division; telephone 713-398-5823, Email 
                        <E T="03">houstonwwm@uscg.mil.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P/>
                <HD SOURCE="HD1">I. Table of Abbreviations</HD>
                <EXTRACT>
                    <FP SOURCE="FP-1">CFR Code of Federal Regulations</FP>
                    <FP SOURCE="FP-1">DHS Department of Homeland Security</FP>
                    <FP SOURCE="FP-1">FR Federal Register</FP>
                    <FP SOURCE="FP-1">NPRM Notice of proposed rulemaking</FP>
                    <FP SOURCE="FP-1">§ Section </FP>
                    <FP SOURCE="FP-1">U.S.C. United States Code</FP>
                </EXTRACT>
                <HD SOURCE="HD1">II. Background, Purpose, and Legal Basis</HD>
                <P>The Coast Guard was informed that an organization will be conducting a fireworks display, annually, during the first week in September and on December 31. The fireworks will be launched from a barge in the Upper Galveston Bay approximately 1000 feet East of the Kemah Boardwalk in Kemah, TX. Hazards from firework displays include accidental discharge of fireworks, dangerous projectiles, and falling hot embers or other debris. The Captain of the Port Sector Houston-Galveston (COTP) has determined that potential hazards associated with the fireworks to be used in this display would be a safety concern for anyone within an 850-foot radius of the barge. This proposed rule would amend 33 CFR 165.801 by adding the September and December 31 dates, as well update location information, for the safety zone identified in TABLE 3 of 33 CFR 165.801, line 3.</P>
                <P>The purpose of this rulemaking is to ensure the safety of vessels and the navigable waters within an 850-foot radius of the fireworks barge before, during, and after the recurring events. The Coast Guard is proposing this rulemaking under authority in 46 U.S.C. 70034.</P>
                <P>The Coast Guard is requesting that interested parties provide comments within a shortened comment period of 15 days instead of the typical 30 days for this notice of proposed rulemaking. The Coast Guard believes the 15-day comment period still provides for a reasonable amount of time for interested parties to review the proposal and provide informed comments on it while also ensuring the Coast Guard has time to review and respond to any significant comments and has a final rule in effect in time for the scheduled event to protect against the identified hazards.</P>
                <P>
                    The Coast Guard anticipates issuing a final rule with an effective date less than 30 days after publication in the 
                    <E T="04">Federal Register</E>
                    . Should that occur, we will explain our good cause for doing so in that publication, as required by 5 U.S.C. 553(d)(3).
                </P>
                <HD SOURCE="HD1">III. Discussion of Proposed Rule</HD>
                <P>The COTP is proposing update location information of a recurring safety zone and add two annually recurring event dates, one during the first week of September and another on December 31. The safety zone would cover all navigable waters within 850 feet of a barge in the Upper Galveston Bay located approximately 1000 feet east of Kemah Boardwalk in Kemah, TX. The safety zone is intended to ensure the safety of vessels and persons on these navigable waters during the scheduled fireworks displays. No vessel or person would be permitted to enter the safety zone without obtaining permission from the COTP or a designated representative. If permission is granted, all persons and vessels must comply with the instructions of the COTP or designated representative. Designated representatives include commissioned, warrant, and petty officers of the U.S. Coast Guard. The regulatory text we are proposing appears at the end of this document.</P>
                <HD SOURCE="HD1">IV. Regulatory Analyses</HD>
                <P>We developed this proposed rule after considering numerous statutes and Executive orders related to rulemaking. Below we summarize our analyses based on a number of these statutes and Executive orders, and we discuss First Amendment rights of protestors.</P>
                <HD SOURCE="HD2">A. Regulatory Planning and Review</HD>
                <P>Executive Orders 12866 and 13563 direct agencies to assess the costs and benefits of available regulatory alternatives and, if regulation is necessary, to select regulatory approaches that maximize net benefits. This NPRM has not been designated a “significant regulatory action,” under section 3(f) of Executive Order 12866, as amended by Executive Order 14094 (Modernizing Regulatory Review). Accordingly, the NPRM has not been reviewed by the Office of Management and Budget (OMB).</P>
                <P>This regulatory action determination is based on the size, duration, and location of the safety zone. The safety zone will last during the scheduled fireworks events and covers an 850-foot radius of navigable waters of Upper Galveston Bay, TX. The zone does not completely restrict vessel traffic and allows mariners to ask for permission to enter the safety zone via VHF radio or contacting the Command Center. The COTP or a designated representative will inform the public through broadcast notices to mariners of the enforcement period for the safety zone as well as any changes in the planned schedule.</P>
                <HD SOURCE="HD2">B. Impact on Small Entities</HD>
                <P>The Regulatory Flexibility Act of 1980, 5 U.S.C. 601-612, as amended, requires Federal agencies to consider the potential impact of regulations on small entities during rulemaking. The term “small entities” comprises small businesses, not-for-profit organizations that are independently owned and operated and are not dominant in their fields, and governmental jurisdictions with populations of less than 50,000. The Coast Guard certifies under 5 U.S.C. 605(b) that this proposed rule would not have a significant economic impact on a substantial number of small entities.</P>
                <P>
                    If you think that your business, organization, or governmental jurisdiction qualifies as a small entity and that this proposed rule would have a significant economic impact on it, please submit a comment (see 
                    <E T="02">ADDRESSES</E>
                    ) explaining why you think it qualifies and how and to what degree this rule would economically affect it.
                </P>
                <P>
                    Under section 213(a) of the Small Business Regulatory Enforcement Fairness Act of 1996 (Pub. L. 104-121), we want to assist small entities in understanding this proposed rule. 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 call or email the person listed in the 
                    <E T="02">FOR FURTHER INFORMATION CONTACT</E>
                     section. The Coast Guard will not retaliate against small entities that question or complain about this proposed rule or any policy or action of the Coast Guard.
                </P>
                <HD SOURCE="HD2">C. Collection of Information</HD>
                <P>This proposed rule would not call for a new collection of information under the Paperwork Reduction Act of 1995 (44 U.S.C. 3501-3520).</P>
                <HD SOURCE="HD2">D. Federalism and Indian Tribal Governments</HD>
                <P>A rule has implications for federalism under Executive Order 13132 (Federalism), if it has a substantial direct effect on the States, on the relationship between the National Government and the States, or on the distribution of power and responsibilities among the various levels of government. We have analyzed this proposed rule under that Order and have determined that it is consistent with the fundamental federalism principles and preemption requirements described in Executive Order 13132.</P>
                <P>
                    Also, this proposed rule does not have tribal implications under Executive 
                    <PRTPAGE P="63333"/>
                    Order 13175 (Consultation and Coordination with Indian Tribal Governments) because it would 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. If you believe this proposed rule has implications for federalism or Indian tribes, please call or email the person listed in the 
                    <E T="02">FOR FURTHER INFORMATION CONTACT</E>
                     section.
                </P>
                <HD SOURCE="HD2">E. Unfunded Mandates Reform Act</HD>
                <P>The Unfunded Mandates Reform Act of 1995 (2 U.S.C. 1531-1538) requires Federal agencies to assess the effects of their discretionary regulatory actions. In particular, the Act addresses actions that may result in the expenditure by a State, local, or tribal government, in the aggregate, or by the private sector of $100,000,000 (adjusted for inflation) or more in any one year. Though this proposed rule would not result in such an expenditure, we do discuss the potential effects of this proposed rule elsewhere in this preamble.</P>
                <HD SOURCE="HD2">F. Environment</HD>
                <P>
                    We have analyzed this proposed rule under Department of Homeland Security Directive 023-01, Rev. 1, associated implementing instructions, and Environmental Planning COMDTINST 5090.1 (series), which guide the Coast Guard in complying with the National Environmental Policy Act of 1969 (42 U.S.C. 4321-4370f), and have made a preliminary determination that this action is one of a category of actions that do not individually or cumulatively have a significant effect on the human environment. This proposed rule involves two safety zones lasting approximately 2 hours that would prohibit entry without permission within 850 feet of a fireworks barge. Normally such actions are categorically excluded from further review under paragraph L[60a] of Appendix A, Table 1 of DHS Instruction Manual 023-01-001-01, Rev. 1. A preliminary Record of Environmental Consideration supporting this determination is available in the docket. For instructions on locating the docket, see the 
                    <E T="02">ADDRESSES</E>
                     section of this preamble. We seek any comments or information that may lead to the discovery of a significant environmental impact from this proposed rule.
                </P>
                <HD SOURCE="HD2">G. Protest Activities</HD>
                <P>
                    The Coast Guard respects the First Amendment rights of protesters. Protesters are asked to call or email the person listed in the 
                    <E T="02">FOR FURTHER INFORMATION CONTACT</E>
                     section to coordinate protest activities so that your message can be received without jeopardizing the safety or security of people, places, or vessels.
                </P>
                <HD SOURCE="HD1">V. Public Participation and Request for Comments</HD>
                <P>We view public participation as essential to effective rulemaking and will consider all comments and material received during the comment period. Your comment can help shape the outcome of this rulemaking. If you submit a comment, please include the docket number for this rulemaking, indicate the specific section of this document to which each comment applies, and provide a reason for each suggestion or recommendation.</P>
                <P>
                    <E T="03">Submitting comments.</E>
                     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-2024-0503 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 you cannot submit your material by using 
                    <E T="03">https://www.regulations.gov,</E>
                     call or email the person in the 
                    <E T="02">FOR FURTHER INFORMATION CONTACT</E>
                     section of this proposed rule for alternate instructions.
                </P>
                <P>
                    <E T="03">Viewing material in docket.</E>
                     To view documents mentioned in this proposed rule as being available in the docket, find the docket as described in the previous paragraph, and then select “Supporting &amp; Related Material” in the Document Type column. Public comments will also be placed in our online docket and can be viewed by following instructions on the 
                    <E T="03">https://www.regulations.gov</E>
                     Frequently Asked Questions web page. Also, if you click on the Dockets tab and then the proposed rule, you should see a “Subscribe” option for email alerts. The option will notify you when comments are posted, or a final rule is published.
                </P>
                <P>We review all comments received, but we will only post comments that address the topic of the proposed rule. We may choose not to post off-topic, inappropriate, or duplicate comments that we receive.</P>
                <P>
                    <E T="03">Personal information.</E>
                     We accept anonymous comments. Comments we post to 
                    <E T="03">https://www.regulations.gov</E>
                     will include any personal information you have provided. For more about privacy and submissions to the docket in response to this document, see DHS's eRulemaking System of Records notice (85 FR 14226, March 11, 2020).
                </P>
                <LSTSUB>
                    <HD SOURCE="HED">List of Subjects in 33 CFR Part 165</HD>
                    <P>Harbors, Marine safety, Navigation (water), Reporting and recordkeeping requirements, Security measures, Waterways.</P>
                </LSTSUB>
                <P>For the reasons discussed in the preamble, the Coast Guard is proposing to amend 33 CFR part 165 as follows:</P>
                <PART>
                    <HD SOURCE="HED">PART 165—REGULATED NAVIGATION AREAS AND LIMITED ACCESS AREAS</HD>
                </PART>
                <AMDPAR>1. The authority citation for part 165 continues to read as follows:</AMDPAR>
                <AUTH>
                    <HD SOURCE="HED">Authority: </HD>
                    <P>46 U.S.C. 70034, 70051, 70124; 33 CFR 1.05-1, 6.04-1, 6.04-6, and 160.5; Department of Homeland Security Delegation No. 00170.1, Revision No. 01.3.</P>
                </AUTH>
                <AMDPAR>2. In § 165.801, amend Table 3, by revising item 3 to read as follows:</AMDPAR>
                <SECTION>
                    <SECTNO>§ 165.801</SECTNO>
                    <SUBJECT>Annual fireworks displays and other events in the Eighth Coast Guard District requiring safety zones.</SUBJECT>
                    <STARS/>
                    <GPOTABLE COLS="4" OPTS="L1,nj,i1" CDEF="s50,r25,xs72,r75">
                        <TTITLE>Table 3 of § 165.801—Sector Houston-Galveston Annual and Recurring Safety Zones</TTITLE>
                        <BOXHD>
                            <CHED H="1">Date</CHED>
                            <CHED H="1">Sponsor/name</CHED>
                            <CHED H="1">
                                Sector Houston-
                                <LI>Galveston location</LI>
                            </CHED>
                            <CHED H="1">Safety zone</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="22"> </ENT>
                        </ROW>
                        <ROW>
                            <ENT I="28">*         *         *         *         *         *         *</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">3. July 4th; every Friday night in June and July; first week of September; December 31</ENT>
                            <ENT>Kemah Boardwalk Fireworks Display, Kemah, TX</ENT>
                            <ENT>Kemah, TX</ENT>
                            <ENT>The area within an 850-foot radius of the fireworks barge located on the south side of Clear Creek Channel, 1000 feet east of Kemah Boardwalk in Kemah, TX.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22"> </ENT>
                        </ROW>
                        <ROW>
                            <ENT I="28">*         *         *         *         *         *         *</ENT>
                        </ROW>
                    </GPOTABLE>
                </SECTION>
                <SIG>
                    <PRTPAGE P="63334"/>
                    <DATED>Dated: July 30, 2024.</DATED>
                    <NAME>Nicole D. Rodriguez,</NAME>
                    <TITLE>Captain, U.S. Coast Guard, Alternate Captain of the Port Sector Houston-Galveston.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17144 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 9110-04-P</BILCOD>
        </PRORULE>
        <PRORULE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF HOMELAND SECURITY</AGENCY>
                <SUBAGY>Coast Guard</SUBAGY>
                <CFR>46 CFR Part 401</CFR>
                <DEPDOC>[Docket No. USCG-2024-0406]</DEPDOC>
                <RIN>RIN 1625-AC94</RIN>
                <SUBJECT>Great Lakes Pilotage Rates—2025 Annual Review</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Coast Guard, DHS.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of proposed rulemaking.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>In accordance with the statutory provisions enacted by the Great Lakes Pilotage Act of 1960, the Coast Guard is proposing new pilotage rates for 2025. The Coast Guard estimates that this proposed rule would result in approximately a 7 percent increase in operating costs compared to the 2024 season. The proposed new pilotage rates are the result of increases in both the number of Pilots and revenue needed for the working capital fund.</P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Comments and related material must be received by the Coast Guard on or before September 4, 2024.</P>
                </EFFDATE>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        You may submit comments identified by docket number USCG-2024-0406 using the Federal Decision-Making Portal at 
                        <E T="03">www.regulations.gov.</E>
                         See the “Public Participation and Request for Comments” portion of the 
                        <E T="02">SUPPLEMENTARY INFORMATION</E>
                         section for further instructions on submitting comments. This notice of proposed rulemaking with its plain-language, 100-word-or-less proposed rule summary will be available in this same docket.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        For information about this document call or email Mr. Brian Rogers, Commandant, Office of Waterways and Ocean Policy—Great Lakes Pilotage Division (CG-WWM-2), Coast Guard; telephone 410-360-9260, email 
                        <E T="03">Brian.Rogers@uscg.mil.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">Table of Contents for Preamble</HD>
                <EXTRACT>
                    <FP SOURCE="FP-2">I. Public Participation and Request for Comments</FP>
                    <FP SOURCE="FP-2">II. Abbreviations</FP>
                    <FP SOURCE="FP-2">III. Basis and Purpose</FP>
                    <FP SOURCE="FP-2">IV. Background</FP>
                    <FP SOURCE="FP-2">V. Summary of the Ratemaking Methodology</FP>
                    <FP SOURCE="FP-2">VI. Discussion of Proposed Rate Adjustments</FP>
                    <FP SOURCE="FP-1">District One</FP>
                    <FP SOURCE="FP1-2">A. Step 1: Recognize Previous Operating Expenses</FP>
                    <FP SOURCE="FP1-2">B. Step 2: Project Operating Expenses, Adjusting for Inflation or Deflation</FP>
                    <FP SOURCE="FP1-2">C. Step 3: Estimate Number of Registered Pilots and Apprentice Pilots</FP>
                    <FP SOURCE="FP1-2">D. Step 4: Determine Target Pilot Compensation Benchmark and Apprentice Pilot Wage Benchmark</FP>
                    <FP SOURCE="FP1-2">E. Step 5: Project Working Capital Fund</FP>
                    <FP SOURCE="FP1-2">F. Step 6: Project Needed Revenue</FP>
                    <FP SOURCE="FP1-2">G. Step 7: Calculate Initial Base Rates</FP>
                    <FP SOURCE="FP1-2">H. Step 8: Calculate Average Weighting Factors by Area</FP>
                    <FP SOURCE="FP1-2">I. Step 9: Calculate Revised Base Rates</FP>
                    <FP SOURCE="FP1-2">J. Step 10: Review and Finalize Rates</FP>
                    <FP SOURCE="FP-1">District Three</FP>
                    <FP SOURCE="FP1-2">A. Step 1: Recognize Previous Operating Expenses</FP>
                    <FP SOURCE="FP1-2">B. Step 2: Project Operating Expenses, Adjusting for Inflation or Deflation</FP>
                    <FP SOURCE="FP1-2">C. Step 3: Estimate Number of Registered Pilots and Apprentice Pilots</FP>
                    <FP SOURCE="FP1-2">D. Step 4: Determine Target Pilot Compensation Benchmark and Apprentice Pilot Wage Benchmark</FP>
                    <FP SOURCE="FP1-2">E. Step 5: Project Working Capital Fund</FP>
                    <FP SOURCE="FP1-2">F. Step 6: Project Needed Revenue</FP>
                    <FP SOURCE="FP1-2">G. Step 7: Calculate Initial Base Rates</FP>
                    <FP SOURCE="FP1-2">H. Step 8: Calculate Average Weighting Factors by Area</FP>
                    <FP SOURCE="FP1-2">I. Step 9: Calculate Revised Base Rates</FP>
                    <FP SOURCE="FP1-2">J. Step 10: Review and Finalize Rates</FP>
                    <FP SOURCE="FP-2">VII. Regulatory Analyses</FP>
                    <FP SOURCE="FP1-2">A. Regulatory Planning and Review</FP>
                    <FP SOURCE="FP1-2">B. Small Entities</FP>
                    <FP SOURCE="FP1-2">C. Assistance for Small Entities</FP>
                    <FP SOURCE="FP1-2">D. Collection of Information</FP>
                    <FP SOURCE="FP1-2">E. Federalism</FP>
                    <FP SOURCE="FP1-2">F. Unfunded Mandates</FP>
                    <FP SOURCE="FP1-2">G. Taking of Private Property</FP>
                    <FP SOURCE="FP1-2">H. Civil Justice Reform</FP>
                    <FP SOURCE="FP1-2">I. Protection of Children</FP>
                    <FP SOURCE="FP1-2">J. Indian Tribal Governments</FP>
                    <FP SOURCE="FP1-2">K. Energy Effects</FP>
                    <FP SOURCE="FP1-2">L. Technical Standards</FP>
                    <FP SOURCE="FP1-2">M. Environment</FP>
                </EXTRACT>
                <HD SOURCE="HD1">I. Public Participation and Request for Comments</HD>
                <P>The Coast Guard views public participation as essential to effective rulemaking and will consider all comments and material received during the comment period. Your comment can help shape the outcome of this rulemaking. If you submit a comment, please include the docket number for this rulemaking, indicate the specific section of this document to which each comment applies, and provide a reason for each suggestion or recommendation.</P>
                <P>
                    <E T="03">Submitting comments.</E>
                     We encourage you to submit comments through the Federal Decision-Making Portal at 
                    <E T="03">www.regulations.gov.</E>
                     To do so, go to 
                    <E T="03">https://www.regulations.gov,</E>
                     type USCG-2024-0406 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 you cannot submit your material by using 
                    <E T="03">www.regulations.gov,</E>
                     call or email the person in the 
                    <E T="02">FOR FURTHER INFORMATION CONTACT</E>
                     section of this proposed rule for alternative instructions.
                </P>
                <P>
                    <E T="03">Viewing material in docket.</E>
                     To view documents mentioned in this proposed rule as being available in the docket, find the docket as described in the previous paragraph, and then select “Supporting &amp; Related Material” in the Document Type column. Public comments will also be placed in our online docket and can be viewed by following instructions on the 
                    <E T="03">www.regulations.gov</E>
                     “Frequently Asked Questions” (FAQ) web page. That FAQ page also explains how to subscribe for email alerts that will notify you when comments are posted or if a final rule is published. We review all comments received, but we will only post comments that address the topic of the proposed rule. We may choose not to post off-topic, inappropriate, or duplicate comments that we receive.
                </P>
                <P>
                    <E T="03">Personal information.</E>
                     We accept anonymous comments. Comments we post to 
                    <E T="03">www.regulations.gov</E>
                     will include any personal information you have provided. For more about privacy and submissions to the docket in response to this document, see DHS's eRulemaking System of Records notice (85 FR 14226, March 11, 2020).
                </P>
                <P>
                    <E T="03">Public meeting.</E>
                     We do not plan to hold a public meeting, but we will consider doing so if we determine from public comments that a meeting would be helpful. We would issue a separate 
                    <E T="04">Federal Register</E>
                     notice to announce the date, time, and location of such a meeting.
                </P>
                <HD SOURCE="HD1">II. Abbreviations</HD>
                <EXTRACT>
                    <FP SOURCE="FP-1">2024 final rule Great Lakes Pilotage Rates—2024 Annual Review</FP>
                    <FP SOURCE="FP-1">2023 final rule Great Lakes Pilotage Rates—2023 Annual Ratemaking and Review of Methodology</FP>
                    <FP SOURCE="FP-1">APA American Pilots' Association</FP>
                    <FP SOURCE="FP-1">BLS Bureau of Labor Statistics</FP>
                    <FP SOURCE="FP-1">CFR Code of Federal Regulations</FP>
                    <FP SOURCE="FP-1">CPI Consumer Price Index</FP>
                    <FP SOURCE="FP-1">DHS Department of Homeland Security</FP>
                    <FP SOURCE="FP-1">Director U.S. Coast Guard's Director of the Great Lakes Pilotage</FP>
                    <FP SOURCE="FP-1">ECI Employment Cost Index</FP>
                    <FP SOURCE="FP-1">FOMC Federal Open Market Committee</FP>
                    <FP SOURCE="FP-1">FR Federal Register</FP>
                    <FP SOURCE="FP-1">GLPAC Great Lakes Pilotage Advisory Committee</FP>
                    <FP SOURCE="FP-1">LPA Lakes Pilots Association</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">PCE Personal Consumption Expenditures</FP>
                    <FP SOURCE="FP-1">§ Section </FP>
                    <FP SOURCE="FP-1">SBA Small Business Administration</FP>
                    <FP SOURCE="FP-1">
                        SLSPA Saint Lawrence Seaway Pilot Association
                        <PRTPAGE P="63335"/>
                    </FP>
                    <FP SOURCE="FP-1">U.S.C. United States Code</FP>
                    <FP SOURCE="FP-1">WGLPA Western Great Lakes Pilots Association</FP>
                </EXTRACT>
                <HD SOURCE="HD1">III. Basis and Purpose</HD>
                <P>
                    The legal basis of this rulemaking is Title 46 of the United States Code (U.S.C.) Chapter 93,
                    <SU>1</SU>
                    <FTREF/>
                     which requires foreign merchant vessels and United States vessels operating “on register” (meaning United States vessels engaged in foreign trade) to use United States or Canadian pilots while transiting the United States waters of the St. Lawrence Seaway and the Great Lakes system.
                    <SU>2</SU>
                    <FTREF/>
                     For U.S. Great Lakes Pilots, the statute requires the Secretary to “prescribe by regulation rates and charges for pilotage services, giving consideration to the public interest and the costs of providing the services.” Title 46 of the U.S.C. 9303(f) also requires that rates be established or reviewed and adjusted each year, no later than March 1. The Secretary's duties and authority under 46 U.S.C. Chapter 93 have generally been delegated to the Coast Guard.
                    <SU>3</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         46 U.S.C. 9301-9308.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>2</SU>
                         46 U.S.C. 9302(a)(1).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>3</SU>
                         Department of Homeland Security (DHS) Delegation No. 00170.1 (II)(92)(f), Revision No. 01.4. The Secretary retains the authority under Section 9307 to establish, and appoint members to, a Great Lakes Pilotage Advisory Committee (GLPAC).
                    </P>
                </FTNT>
                <P>The purpose of this proposed rule is to issue new pilotage rates for 2025. The Coast Guard believes that the new rates will continue to promote our goal, as outlined in title 46 of the Code of Federal Regulations (CFR), 404.1(a), to promote safe, efficient, and reliable pilotage service in the Great Lakes by generating sufficient revenue for each pilot association to reimburse its necessary and reasonable operating expenses, fairly compensate trained and rested Pilots, and provide appropriate funds to use for improvements.</P>
                <HD SOURCE="HD1">IV. Background</HD>
                <P>Rates are the foundation for safe, efficient, and reliable pilotage service to facilitate maritime commerce, protect the marine environment, and comply with National Transportation Safety Board recommendations regarding staffing and pilot fatigue. The pilotage rates for the 2025 season range from a proposed $438 to $981 per pilot hour, depending on which of the specific 6 areas pilotage service is provided. The rates are paid by shippers to the pilot associations.</P>
                <P>
                    There are three American pilotage districts on the Great Lakes, each represented by a pilot association.
                    <SU>4</SU>
                    <FTREF/>
                     Each pilotage district is further divided into “designated” and “undesignated” areas. Designated areas, classified as such by Presidential Proclamation, are waters in which pilots must direct the navigation of vessels at all times.
                    <SU>5</SU>
                    <FTREF/>
                     Undesignated areas are open bodies of water where pilots must only “be on board and available to direct the navigation of the vessel” at the discretion of the vessel master.
                    <SU>6</SU>
                    <FTREF/>
                     For these reasons, pilotage rates in designated areas can be significantly higher than those in undesignated areas.
                </P>
                <FTNT>
                    <P>
                        <SU>4</SU>
                         The Saint Lawrence Seaway Pilotage Association (SLSPA) provides pilotage services in District One, which includes all U.S. waters of the St. Lawrence River and Lake Ontario. The Lakes Pilots Association (LPA) provides pilotage services in District Two, which includes all U.S. waters of Lake Erie, the Detroit River, Lake St. Clair, and the St. Clair River. Finally, the Western Great Lakes Pilots Association (WGLPA) provides pilotage services in District Three, which includes all U.S. waters of the St. Marys River; Sault Ste. Marie Locks; and Lakes Huron, Michigan, and Superior.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>5</SU>
                         Presidential Proclamation 3385, 
                        <E T="03">Designation of restricted waters under the Great Lakes Pilotage Act of 1960,</E>
                         December 22, 1960 (
                        <E T="03">https://www.archives.gov/federal-register/codification/proclamations/03385.html</E>
                        ) (last accessed 5/01/24).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>6</SU>
                         46 U.S.C. 9302(a)(1)(B).
                    </P>
                </FTNT>
                <P>
                    The three pilot associations, which are the exclusive U.S. source of Registered Pilots on the Great Lakes, use the revenue from the shippers to cover operating expenses, maintain infrastructure, compensate Apprentice and Registered Pilots, acquire and implement technological advances, train new personnel, and provide for continuing professional development. Each pilot association is an independent business and is the sole provider of pilotage services in its district of operation. Each pilot association is responsible for funding its own operating expenses, infrastructure maintenance, and compensation for Pilots and Apprentice Pilots.
                    <SU>7</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>7</SU>
                         Apprentice Pilots and Applicant Pilots are compensated by the pilot association they are training with, which is funded through the pilotage rates. The ratemaking methodology accounts for an Apprentice Pilot wage benchmark in Step 4 per 46 CFR 404.104(d). The Applicant Pilot salaries are included in the pilot associations' operating expenses used in Step 1 per 46 CFR 404.101.
                    </P>
                </FTNT>
                <P>The actual demand for service dictates the compensation amount for United States Registered Pilots. We divide that amount by the historic 10-year average for pilotage demand. We recognize that, in years where demand for pilotage services exceeds the 10-year average, pilot associations will accrue more revenue than projected, while, in years where demand is below average, they will take in less. We believe that, over the long term, however, this scheme ensures that infrastructure will be maintained, and that Pilots will receive adequate compensation and work a reasonable number of hours, with adequate rest between assignments, to ensure retention of highly trained personnel.</P>
                <P>In this notice of proposed rulemaking (NPRM), we are conducting our annual review and interim adjustment to the base pilotage rates for 2025. The Coast Guard last conducted a full ratemaking in 2023, with the “Great Lakes Pilotage Rates—2023 Annual Ratemaking and Review of Methodology” final rule (hereafter the “2023 final rule”) (88 FR 12226, published February 27, 2023). This proposed rule is an interim ratemaking under 46 CFR 404.100(b).</P>
                <HD SOURCE="HD1">V. Summary of the Ratemaking Methodology</HD>
                <P>The ratemaking methodology, outlined in 46 CFR 404.101 through 404.110, consists of 10 steps that are designed to account for the revenues needed and total traffic expected in each district. The first several steps of the methodology establish base pilotage rates. Additional steps to incorporate the weighting factors are necessary to establish the final pilotage rates. The result is an hourly rate, determined separately for each of the areas administered by the Coast Guard.</P>
                <P>In Step 1, “Recognize previous operating expenses,” (§ 404.101), the U.S. Coast Guard's Director of the Great Lakes Pilotage (“Director”) uses an independent third party to review each pilot association's audited operating expenses from each of the three pilot associations. Operating expenses include all allowable expenses, minus Pilot and Apprentice Pilot wages and benefits. This number forms the baseline amount that each association is budgeted. Because of the time delay between when the association submits raw numbers and when the Coast Guard receives audited numbers, this number is 3 years behind the projected year of expenses. Therefore, in calculating the 2025 rates in this proposal, we begin with the audited expenses from the shipping activity in 2022.</P>
                <P>
                    While each pilot association operates in an entire district (including both designated and undesignated areas), the Coast Guard determines costs by area. We allocate certain operating expenses to designated areas and certain operating expenses to undesignated areas. In some cases, we can allocate the costs based on where they are accrued. For example, we can allocate the costs of insurance for Apprentice Pilots who operate in undesignated areas only. In other situations, such as general legal expenses, expenses are distributed between designated and undesignated waters on a “pro rata” basis, based upon the proportion of income forecasted from the respective portions of the district.
                    <PRTPAGE P="63336"/>
                </P>
                <P>In Step 2, “Project operating expenses, adjusting for inflation or deflation,” (§ 404.102), the Director develops the 2025 projected operating expenses. To do this, we apply inflation adjustors for 3 years to the operating expense baseline received in Step 1. The inflation factors are from the Bureau of Labor Statistics' (BLS) Consumer Price Index (CPI) for the Midwest Region, or, if not available, the Federal Open Market Committee (FOMC) median economic projections for Personal Consumption Expenditures (PCE) inflation. This step produces the total operating expenses for each area and district.</P>
                <P>In Step 3, “Estimate number of Registered Pilots and Apprentice Pilots,” (§ 404.103), the Director calculates how many Registered and Apprentice Pilots are needed for each district. To do this, we employ a “staffing model,” described in § 401.220, paragraphs (a)(1) through (3), to estimate how many Pilots would be needed to handle shipping during the beginning and close of the season. This number provides guidance to the Director in approving an appropriate number of Pilots.</P>
                <P>
                    At the September 7, 2023 GLPAC meeting, there was a unanimous recommendation for an August 1 cutoff date to allow an Apprentice Pilot, who has completed all their training, to be recognized as a fully registered Pilot in the rate.
                    <SU>8</SU>
                    <FTREF/>
                     The Coast Guard agrees that this change is both necessary and reasonable, as it provides the proper compensation based on the most accurate data. If an Apprentice Pilot is scheduled to complete training and becomes a fully registered Pilot before August 1, they will be counted as a fully registered Pilot in the rate; but if they do not meet the August 1 deadline, those funds may be adjusted in the proceeding rate for up to the full amount. In addition, if a fully registered Pilot retires, or an Apprentice Pilot quits, and has been counted in the rate, the proceeding rate may be adjusted according for up to the full amount.
                </P>
                <FTNT>
                    <P>
                        <SU>8</SU>
                         Transcript of United States Coast Guard Great Lakes Pilotage Advisory Committee Meeting at 97 (Sept. 7, 2023), 
                        <E T="03">https://www.regulations.gov/document/USCG-2023-0438-0009</E>
                         (last accessed 05/31/2024) (last accessed 05/31/2024).
                    </P>
                </FTNT>
                <P>In Step 4 of the ratemaking calculation, we determine the number of Pilots provided by the pilot associations (see § 404.103) and use that figure to determine how many Pilots need to be compensated via the pilotage fees collected. In the first part of Step 4, “Determine target Pilot compensation benchmark and Apprentice Pilot wage benchmark,” (§ 404.104(b)(1)), the Director adjusts the previous year's individual target Pilot compensation by the difference between the previous year's BLS Employment Cost Index for the Transportation and Materials sector and the FOMC median economic projections for Personal Consumption Expenditures inflation value used to inflate the previous year's target Pilot compensation.</P>
                <P>In the second part of Step 4, (§ 404.104(b)(2)), the Director then adjusts that value by the FOMC median economic projections for Personal Consumption Expenditures inflation for the upcoming year.</P>
                <P>In the final part of Step 4, § 404.104(c) and (d), the Director determines the total target compensation figure for each district. To do this, the Director multiplies the compensation benchmark by the number of Pilots for each area and district (from Step 3), producing a figure for total Pilot compensation. Based on the total Pilot compensation, the Director determines the individual Apprentice Pilot wage benchmark at the rate of 36 percent of the individual target Pilot compensation, as calculated according to paragraphs (a) or (b) of this section.</P>
                <P>In Step 5, “Project working capital fund,” (§ 404.105), the Director calculates an added value to pay for needed capital improvements and other non-recurring expenses, such as technology investments and infrastructure maintenance. This value is calculated by adding the total operating expenses (derived in Step 2) to the total target Pilot compensation and the total target Apprentice Pilot wage (derived in Step 4), then by multiplying that figure by the preceding year's average annual rate of return for new issues of high-grade corporate securities. This figure constitutes the “working capital fund” for each area and district.</P>
                <P>In Step 6, “Project needed revenue,” (§ 404.106), the Director simply adds the totals produced by the preceding steps. The projected operating expenses for each area and district (from Step 2) is added to the total Pilot compensation, including Apprentice Pilot wage benchmarks (from Step 4), and the working capital fund contribution (from Step 5). The total figure, calculated separately for each area and district, is the “needed revenue.”</P>
                <P>In Step 7, “Calculate initial base rates,” (§ 404.107), the Director calculates an hourly pilotage rate to cover the needed revenue, as calculated in Step 6. This step consists of first calculating the 10-year average of traffic hours for each area. Next, we divide the revenue needed in each area (calculated in Step 6) by the 10-year average of traffic hours to produce an initial base rate.</P>
                <P>An additional element, the “weighting factor,” is required under § 401.400. Pursuant to that section, ships pay a multiple of the “base rate,” as calculated in Step 7, by a number ranging from 1.0 (for the smallest ships, or “Class I” vessels) to 1.45 (for the largest ships, or “Class IV” vessels). This significantly increases the revenue collected, and we need to account for the added revenue produced by the weighting factors to ensure that shippers are not overpaying for pilotage services. We do this in the next step.</P>
                <P>In Step 8, “Calculate average weighting factors by Area,” (§ 404.108), the Director calculates how much extra revenue, as a percentage of total revenue, has historically been produced by the weighting factors in each area. We do this by using a historical average of the applied weighting factors for each year since 2014 (the first year the current weighting factors were applied).</P>
                <P>In Step 9, “Calculate revised base rates,” (§ 404.109), the Director modifies the base rates by accounting for the extra revenue generated by the weighting factors. We do this by dividing the initial pilotage rate for each area (from Step 7) by the corresponding average weighting factor (from Step 8), to produce a revised rate.</P>
                <P>In Step 10, “Review and finalize rates,” (§ 404.110), often referred to informally as “Director's discretion”, the Director reviews the revised base rates (from Step 9) to ensure that they meet the goals set forth in 46 U.S.C. 9303(f) and 46 CFR 404.1(a), which include promoting efficient, safe, and reliable pilotage service on the Great Lakes; generating sufficient revenue for each pilot association to reimburse necessary and reasonable operating expenses; compensating trained and rested pilots fairly; and providing appropriate revenue for improvements.</P>
                <HD SOURCE="HD1">VI. Discussion of Proposed Rate Adjustments</HD>
                <P>In this NPRM, we are proposing new pilotage rates for 2025. We propose to conduct the 2025 ratemaking as an interim ratemaking, as we did in the 2024 ratemaking (89 FR 9038). Thus, the Coast Guard proposes to adjust the compensation benchmark following the interim ratemaking procedures under § 404.100(b), rather than following the procedures for a full ratemaking under § 404.100(a).</P>
                <P>
                    This section discusses the proposed rate changes using the ratemaking steps provided in 46 CFR part 404. We will detail all 10 steps of the ratemaking 
                    <PRTPAGE P="63337"/>
                    procedure for each of the 3 districts to show how we arrive at the proposed new rates.
                </P>
                <P>The Coast Guard is proposing the rates shown in table 1.</P>
                <GPH SPAN="3" DEEP="355">
                    <GID>EP05AU24.093</GID>
                </GPH>
                <P>This proposed rule would affect 61 U.S. Great Lakes Pilots, 3 Apprentice Pilots, 3 pilot associations, and the owners and operators of an average of 280 oceangoing vessels that transit the Great Lakes annually. This proposed rule would not affect the Coast Guard's budget or increase Federal spending, because foreign shippers, foreign cruise ships, and vessels requesting voluntary pilotage pay these rates directly to the respective pilot association The estimated overall annual regulatory economic impact of this rate change would be a net increase of $2,639,968 in payments made by the foreign shippers, foreign cruise ships, and vessels requesting voluntary pilotage service, a seven percent increase from operating costs in the 2024 shipping season. This represents an increase in revenue needed for target Pilot compensation, a decrease in revenue needed for the total Apprentice Pilot wage benchmark, an increase in the revenue needed for adjusted operating expenses, and an increase in the revenue needed for the working capital fund.</P>
                <P>This proposed rule would establish the 2025 yearly target compensation for Pilots on the Great Lakes at $461,611 per Pilot (a $20,953, or 4.75 percent, increase over their 2024 target compensation). Because the Coast Guard must review, and, if necessary, adjust rates each year, we analyze these as single-year costs and do not annualize them over 10 years. Section VII., Regulatory Analyses, in this preamble provides the regulatory impact analyses of this proposed rule. The following work demonstrates how we arrived at the proposed rate for each pilotage district.</P>
                <HD SOURCE="HD2">District One</HD>
                <HD SOURCE="HD3">A. Step 1: Recognize Previous Operating Expenses</HD>
                <P>
                    Step 1 in the ratemaking methodology requires that the Coast Guard review and recognize the operating expenses for the last full year for which figures are available (§ 404.101). To do so, we begin by reviewing the independent accountant's financial reports for each association's 2022 expenses and revenues.
                    <SU>9</SU>
                    <FTREF/>
                     For accounting purposes, the financial reports divide expenses into designated and undesignated areas. For costs accrued by the pilot associations generally, such as employee benefits, the cost is divided between the designated and undesignated areas on a pro rata basis. Adjustments have been made by the auditors and are explained in the auditor's reports, which are available in the docket for this 
                    <PRTPAGE P="63338"/>
                    rulemaking, where indicated under Section I., Public Participation and Request for Comments.
                </P>
                <FTNT>
                    <P>
                        <SU>9</SU>
                         These reports are available in the docket for this proposed rule.
                    </P>
                </FTNT>
                <P>The recognized operating expenses for District One are shown in table 2.</P>
                <BILCOD>BILLING CODE 9110-04-P</BILCOD>
                <GPH SPAN="3" DEEP="619">
                    <GID>EP05AU24.094</GID>
                </GPH>
                <GPH SPAN="3" DEEP="619">
                    <PRTPAGE P="63339"/>
                    <GID>EP05AU24.095</GID>
                </GPH>
                <BILCOD>BILLING CODE 9110-04-C</BILCOD>
                <HD SOURCE="HD3">B. Step 2: Project Operating Expenses, Adjusting for Inflation or Deflation</HD>
                <P>
                    In accordance with the text in § 404.102, having identified the recognized 2022 operating expenses in Step 1, the next step is to estimate the current year's operating expenses by adjusting for inflation over the 3-year 
                    <PRTPAGE P="63340"/>
                    period. We calculate inflation using the BLS data from the CPI for the Midwest Region of the United States for the 2023 inflation rate.
                    <SU>10</SU>
                    <FTREF/>
                     Because the BLS does not provide forecasted inflation data, we use economic projections from the Federal Reserve for the 2024 and 2025 inflation modification.
                    <SU>11</SU>
                    <FTREF/>
                     Based on that information, the calculations for Step 2 are as presented in table 3.
                </P>
                <FTNT>
                    <P>
                        <SU>10</SU>
                         The CPI is defined as “All Urban Consumers (CPI-U), All Items, 1982-4=100.” Series CUUR0200SA0 (Downloaded February 22, 2024). Available at 
                        <E T="03">https://www.bls.gov/cpi/data.htm.,</E>
                         All Urban Consumers (Current Series), multiscreen data, not seasonally adjusted, 0200 Midwest, Current, All Items, Monthly, 12-month Percent Change and Annual Data (last accessed 05/31/2024).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>11</SU>
                         The 2024 and 2025 inflation rates are available at 
                        <E T="03">https://www.federalreserve.gov/monetarypolicy/files/fomcprojtabl20240320.pdf.</E>
                         We used the Core PCE December Projection found in table 1. (Downloaded March 2024).
                    </P>
                </FTNT>
                <GPH SPAN="3" DEEP="136">
                    <GID>EP05AU24.096</GID>
                </GPH>
                <HD SOURCE="HD3">C. Step 3: Estimate Number of Registered Pilots and Apprentice Pilots</HD>
                <P>
                    In accordance with the text in §  404.103, the Coast Guard estimates the number of fully registered Pilots in each district. In the past, this was done using the staffing model and the process described in §  404.103. Last year, during the 2023 GLPAC meeting, there was a unanimous recommendation by the GLPAC that, after 2024, the Director be given discretion to increase the staffing model plus three Pilots per District, based on industry demand and to ensure shipping reliability.
                    <SU>12</SU>
                    <FTREF/>
                     Additionally, the previous staffing model's maximum is now considered the minimum in regard to the number of Pilots needed in each district.
                    <SU>13</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>12</SU>
                         Transcript, 
                        <E T="03">supra</E>
                         note 8, at 89-90.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>13</SU>
                         
                        <E T="03">Id.</E>
                         at 57-58.
                    </P>
                </FTNT>
                <P>We determine the number of fully registered Pilots based on data provided by the SLSPA as well as the previously mentioned recommendation. We determine the number of Apprentice Pilots based on input from the district on anticipated retirements and staffing needs. These numbers can be found in table 4.</P>
                <GPH SPAN="3" DEEP="95">
                    <GID>EP05AU24.097</GID>
                </GPH>
                <HD SOURCE="HD3">D. Step 4: Determine Target Pilot Compensation Benchmark and Apprentice Pilot Wage Benchmark</HD>
                <P>
                    In this step, we determine the total target Pilot compensation for each area. Because we are issuing an interim ratemaking this year, we follow the procedure outlined in paragraph (b) of § 404.104, which adjusts the existing compensation benchmark by inflation. First, we adjust the 2024 target compensation benchmark of $440,658 by 2.5 percent for a value of $451,674. This accounts for the difference in actual first quarter 2024 Employment Cost Index (ECI) inflation, which is 5.1 percent, and the 2024 PCE estimate of 2.6 percent.
                    <E T="51">14 15</E>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>14</SU>
                         Employment Cost Index, Total Compensation for Private Industry workers in Transportation and Material Moving, Annual Average, Series ID: CIU2010000520000A. 
                        <E T="03">https://www.bls.gov/news.release/eci.t05.htm</E>
                         (last accessed 04/30/24).
                    </P>
                    <P>
                        <SU>15</SU>
                         2.6 percent was the latest figure available for the 2024 final rule. Table 1, Summary of Economic Projections, Median Core PCE Inflation June Projection. 
                        <E T="03">https://www.federalreserve.gov/monetarypolicy/files/fomcprojtabl20230920.pdf</E>
                         (last accessed 05/31/2024).
                    </P>
                </FTNT>
                <P>
                    The second step accounts for projected inflation from 2024 to 2025, which is 2.2 percent.
                    <SU>16</SU>
                    <FTREF/>
                     Based on the projected 2025 inflation estimate, the proposed target compensation benchmark for 2025 is $461,611 per pilot. The proposed Apprentice Pilot wage benchmark is 36 percent of the target Pilot compensation, or $166,180 ($461,611 × 0.36).
                </P>
                <FTNT>
                    <P>
                        <SU>16</SU>
                         Table 1, Summary of Economic Projections, Median Core PCE Inflation December Projection. 
                        <E T="03">https://www.federalreserve.gov/monetarypolicy/files/fomcprojtabl20240320.pdf. (</E>
                        Downloaded March 2024).
                    </P>
                </FTNT>
                <P>
                    In accordance with § 404.104(c), we use the revised target individual compensation level to derive the total Pilot compensation by multiplying the individual target compensation by the estimated number of Registered Pilots for District One, as shown in table 5. We estimate that the number of Apprentice Pilots needed will be one for District One in the 2025 rulemaking. The total target wages for Apprentice Pilots are allocated with 60 percent for the 
                    <PRTPAGE P="63341"/>
                    designated area and 40 percent for the undesignated area, in accordance with the allocation for operating expenses.
                </P>
                <GPH SPAN="3" DEEP="186">
                    <GID>EP05AU24.098</GID>
                </GPH>
                <HD SOURCE="HD3">E. Step 5: Project Working Capital Fund</HD>
                <P>
                    Next, the Coast Guard calculates the working capital fund revenues needed for each area. We first add the figures for projected operating expenses, total target Pilot compensation, and total target Apprentice Pilot wage for each area. Then we find the preceding year's average annual rate of return for new issues of high-grade corporate securities. Using Moody's data, the number is 4.8100 percent, rounded.
                    <SU>17</SU>
                    <FTREF/>
                     By multiplying the two figures, we obtain the working capital fund contribution for each area, as shown in table 6.
                </P>
                <FTNT>
                    <P>
                        <SU>17</SU>
                         Moody's Seasoned Aaa Corporate Bond Yield, average of 2023 monthly data. The Coast Guard uses the most recent year of complete data. Moody's is taken from Moody's Investors Service, which is a bond credit rating business of Moody's Corporation. Bond ratings are based on creditworthiness and risk. The rating of “Aaa” is the highest bond rating assigned with the lowest credit risk. 
                        <E T="03">See https://fred.stlouisfed.org/series/AAA</E>
                         (last accessed 01/08/2024).
                    </P>
                </FTNT>
                <GPH SPAN="3" DEEP="282">
                    <GID>EP05AU24.099</GID>
                </GPH>
                <PRTPAGE P="63342"/>
                <HD SOURCE="HD3">F. Step 6: Project Needed Revenue</HD>
                <P>In this step, we add the expenses accrued to derive the total revenue needed for each area. These expenses include the projected operating expenses (from Step 2), the total target Pilot compensation (from Step 4), total target Apprentice Pilot wage (from Step 4), and the working capital fund contribution (from Step 5). We show these calculations in table 7.</P>
                <GPH SPAN="3" DEEP="147">
                    <GID>EP05AU24.100</GID>
                </GPH>
                <HD SOURCE="HD3">G. Step 7: Calculate Initial Base Rates</HD>
                <P>Having determined the revenue needed for each area in the previous six steps, we divide that number by the expected number of traffic hours to develop an hourly rate.</P>
                <P>
                    Step 7 is a two-part process. The first part entails calculating the 10-year traffic average in District One, using the total time on task or Pilot bridge hours. To calculate the time on task for each district, the Coast Guard used billing data from SeaPro. The Coast Guard received revised 2022 bridge hours in the revenue reports submitted by our third-party auditor and has implemented them into the rate in this step of the rulemaking.
                    <SU>18</SU>
                    <FTREF/>
                     Because we calculate separate figures for designated and undesignated waters, there are two parts for each calculation. We show these values in table 8.
                </P>
                <FTNT>
                    <P>
                        <SU>18</SU>
                         
                        <E T="03">See</E>
                         details on the revised figures in Section VII., Regulatory Analyses.
                    </P>
                </FTNT>
                <GPH SPAN="3" DEEP="209">
                    <GID>EP05AU24.101</GID>
                </GPH>
                <P>Next, we derive the initial hourly rate by dividing the revenue needed by the average number of hours for each area. This produces an initial rate, which is necessary to produce the revenue needed for each area, assuming the amount of traffic is as expected. We present the calculations for District One in table 9.</P>
                <GPH SPAN="3" DEEP="82">
                    <PRTPAGE P="63343"/>
                    <GID>EP05AU24.102</GID>
                </GPH>
                <HD SOURCE="HD3">H. Step 8: Calculate Average Weighting Factors by Area</HD>
                <P>In this step, the Coast Guard calculates the average weighting factor for each designated and undesignated area by first collecting the weighting factors, set forth in 46 CFR 401.400, for each vessel trip. Using the weight factor report from SeaPro, we calculate the average weighting factor for each area using the data from each vessel transit from 2014 onward, as shown in tables 10 and 11.</P>
                <BILCOD>BILLING CODE 9110-04-P</BILCOD>
                <GPH SPAN="3" DEEP="402">
                    <GID>EP05AU24.103</GID>
                </GPH>
                <GPH SPAN="3" DEEP="380">
                    <PRTPAGE P="63344"/>
                    <GID>EP05AU24.104</GID>
                </GPH>
                <GPH SPAN="3" DEEP="307">
                    <PRTPAGE P="63345"/>
                    <GID>EP05AU24.105</GID>
                </GPH>
                <GPH SPAN="3" DEEP="475">
                    <PRTPAGE P="63346"/>
                    <GID>EP05AU24.106</GID>
                </GPH>
                <BILCOD>BILLING CODE 9110-04-C</BILCOD>
                <HD SOURCE="HD3">I. Step 9: Calculate Revised Base Rates</HD>
                <P>In this step, we revise the base rates so that the total cost of pilotage will be equal to the revenue needed, after considering the impact of the weighting factors. To do this, we divide the initial base rates calculated in Step 7 by the average weighting factors calculated in Step 8, as shown in table 12.</P>
                <GPH SPAN="3" DEEP="146">
                    <PRTPAGE P="63347"/>
                    <GID>EP05AU24.107</GID>
                </GPH>
                <HD SOURCE="HD3">J. Step 10: Review and Finalize Rates</HD>
                <P>In this step, the Director reviews the base pilotage rates calculated in § 404.109 of this part to ensure it meets the goal of ensuring safe, efficient, and reliable pilotage service. To establish this, the Director considers whether the proposed rates incorporate appropriate compensation for Pilots to handle heavy traffic periods and whether there are enough Pilots to handle those heavy traffic periods. The Director also considers whether the proposed rates would cover operating expenses and infrastructure costs, including average traffic and weighting factors. Based on these considerations, the Director is not proposing any alterations to the rates in this step. We propose to modify § 401.405(a)(1) and (2) to reflect the final rates shown in table 13.</P>
                <GPH SPAN="3" DEEP="147">
                    <GID>EP05AU24.108</GID>
                </GPH>
                <HD SOURCE="HD2">District Two</HD>
                <HD SOURCE="HD3">A. Step 1: Recognize Previous Operating Expenses</HD>
                <P>
                    Step 1 in our ratemaking methodology requires that the Coast Guard review and recognize the previous year's operating expenses (§ 404.101). To do so, we begin by reviewing the independent accountant's financial reports for each association's 2022 expenses and revenues.
                    <SU>19</SU>
                    <FTREF/>
                     For accounting purposes, the financial reports divide expenses into designated and undesignated areas. For costs generally accrued by the pilot associations, such as employee benefits, the cost is divided between the designated and undesignated areas on a pro rata basis. Adjustments have been made by the auditors and are explained in the auditor's reports, which are available in the docket for this rulemaking, where indicated under Section I., Public Participation and Request for Comments.
                </P>
                <FTNT>
                    <P>
                        <SU>19</SU>
                         These reports are available in the docket for this proposed rule.
                    </P>
                </FTNT>
                <P>The recognized operating expenses for District Two are shown in table 14.</P>
                <BILCOD>BILLING CODE 9110-04-P</BILCOD>
                <GPH SPAN="3" DEEP="616">
                    <PRTPAGE P="63348"/>
                    <GID>EP05AU24.109</GID>
                </GPH>
                <GPH SPAN="3" DEEP="616">
                    <PRTPAGE P="63349"/>
                    <GID>EP05AU24.110</GID>
                </GPH>
                <BILCOD>BILLING CODE 9110-04-C</BILCOD>
                <HD SOURCE="HD3">B. Step 2: Project Operating Expenses, Adjusting for Inflation or Deflation</HD>
                <P>
                    In accordance with the text in § 404.102, having identified the recognized 2022 operating expenses in Step 1, the next step is to estimate the current year's operating expenses by adjusting for inflation over the 3-year 
                    <PRTPAGE P="63350"/>
                    period. We calculate inflation using the BLS data from the CPI for the Midwest Region of the United States for the 2023 inflation rate.
                    <SU>20</SU>
                    <FTREF/>
                     Because the BLS does not provide forecasted inflation data, we use economic projections from the Federal Reserve for the 2024 and 2025 inflation modification.
                    <SU>21</SU>
                    <FTREF/>
                     Based on that information, the calculations for Step 2 are presented in table 15.
                </P>
                <FTNT>
                    <P>
                        <SU>20</SU>
                         CPI, 
                        <E T="03">supra</E>
                         note 10.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>21</SU>
                         Core PCE December Projection, 
                        <E T="03">supra</E>
                         note 11.
                    </P>
                </FTNT>
                <GPH SPAN="3" DEEP="184">
                    <GID>EP05AU24.111</GID>
                </GPH>
                <HD SOURCE="HD3">C. Step 3: Estimate Number of Registered Pilots and Apprentice Pilots</HD>
                <P>
                    In accordance with the text in §  404.103, the Coast Guard estimates the number of fully registered Pilots in each district. In the past, this was done using the staffing model and the process described in §  404.103. Last year, during the 2023 GLPAC meeting, there was a unanimous recommendation by the GLPAC that, after 2024, the Director be given discretion to increase the staffing model plus three Pilots per District, based on industry demand and to ensure shipping reliability.
                    <SU>22</SU>
                    <FTREF/>
                     Additionally, the previous staffing model's maximum is now considered the minimum in regard to the number of Pilots needed in each district.
                    <SU>23</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>22</SU>
                         Transcript, 
                        <E T="03">supra</E>
                         note 8 at 89-90.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>23</SU>
                         
                        <E T="03">Id.</E>
                         at 57-58.
                    </P>
                </FTNT>
                <P>We determine the number of fully registered Pilots based on data provided by the LPA as well as the previous mentioned recommendation. We determine the number of Apprentice Pilots based on input from the district on anticipated retirements and staffing needs. These numbers can be found in table 16.</P>
                <GPH SPAN="3" DEEP="95">
                    <GID>EP05AU24.112</GID>
                </GPH>
                <HD SOURCE="HD3">D. Step 4: Determine Target Pilot Compensation Benchmark and Apprentice Pilot Wage Benchmark</HD>
                <P>
                    In this step, we determine the total target Pilot compensation for each area. Because we are issuing an interim ratemaking this year, we follow the procedure outlined in paragraph (b) of § 404.104, which adjusts the existing compensation benchmark by inflation. First, we adjust the 2024 target compensation benchmark of $440,658 by 2.5 percent for a value of $451,674. This accounts for the difference in actual first quarter 2024 ECI inflation, which is 5.1 percent, and the 2024 PCE estimate of 2.6 percent.
                    <E T="51">24 25</E>
                    <FTREF/>
                     The second step accounts for projected inflation from 2024 to 2025, which is 2.2 percent.
                    <SU>26</SU>
                    <FTREF/>
                     Based on the projected 2025 inflation estimate, the proposed target compensation benchmark for 2025 is $461,611 per Pilot. The proposed Apprentice Pilot wage benchmark is 36 percent of the target Pilot compensation, or $166,180 ($461,611 × 0.36).
                </P>
                <FTNT>
                    <P>
                        <SU>24</SU>
                         ECI, 
                        <E T="03">supra</E>
                         note 14.
                    </P>
                    <P>
                        <SU>25</SU>
                         Median Core PCE Inflation June Projection, 
                        <E T="03">supra</E>
                         note 15.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>26</SU>
                         Median Core PCE Inflation December Projection, 
                        <E T="03">supra</E>
                         note 16.
                    </P>
                </FTNT>
                <P>In accordance with § 404.104(c), we use the revised target individual compensation level to derive the total Pilot compensation by multiplying the individual target compensation by the estimated number of Registered Pilots for District Two, as shown in table 17. The total target wages for Apprentice Pilots are allocated with 60 percent for the designated area and 40 percent for the undesignated area, in accordance with the allocation for operating expenses.</P>
                <GPH SPAN="3" DEEP="188">
                    <PRTPAGE P="63351"/>
                    <GID>EP05AU24.113</GID>
                </GPH>
                <HD SOURCE="HD3">E. Step 5: Project Working Capital Fund</HD>
                <P>
                    Next, the Coast Guard calculates the working capital fund revenues needed for each area. We first add the figures for projected operating expenses, total target Pilot compensation, and total target Apprentice Pilot wage for each area. Then we find the preceding year's average annual rate of return for new issues of high-grade corporate securities. Using Moody's data, the number is 4.8100 percent, rounded.
                    <SU>27</SU>
                    <FTREF/>
                     By multiplying the two figures, we obtain the working capital fund contribution for each area, as shown in table 18.
                </P>
                <FTNT>
                    <P>
                        <SU>27</SU>
                         Moody's Seasoned Aaa Corporate Bond Yield, 
                        <E T="03">supra</E>
                         note 17.
                    </P>
                </FTNT>
                <GPH SPAN="3" DEEP="146">
                    <GID>EP05AU24.114</GID>
                </GPH>
                <HD SOURCE="HD3">F. Step 6: Project Needed Revenue</HD>
                <P>In this step, the Coast Guard adds all the expenses accrued to derive the total revenue needed for each area. These expenses include the projected operating expenses (from Step 2), the total target Pilot compensation (from Step 4), total target Apprentice Pilot wage (from Step 4), and the working capital fund contribution (from Step 5). We show these calculations in table 19.</P>
                <GPH SPAN="3" DEEP="147">
                    <GID>EP05AU24.115</GID>
                </GPH>
                <PRTPAGE P="63352"/>
                <HD SOURCE="HD3">G. Step 7: Calculate Initial Base Rates</HD>
                <P>Having determined the revenue needed for each area in the previous six steps, we divide that number by the expected number of traffic hours to develop an hourly rate.</P>
                <P>
                    Step 7 is a two-part process. The first part entails calculating the 10-year traffic average in District Two, using the total time on task or Pilot bridge hours. To calculate the time on task for each district, the Coast Guard used billing data from SeaPro. The Coast Guard received revised 2022 bridge hours in the revenue reports submitted by our third-party auditor and has implemented them into the rate in this step of the rulemaking.
                    <SU>28</SU>
                    <FTREF/>
                     Because we calculate separate figures for designated and undesignated waters, there are two parts for each calculation. We show these values in table 20.
                </P>
                <FTNT>
                    <P>
                        <SU>28</SU>
                         See details on the revised figures in Section VII., Regulatory Analyses.
                    </P>
                </FTNT>
                <GPH SPAN="3" DEEP="212">
                    <GID>EP05AU24.116</GID>
                </GPH>
                <P>Next, we derive the initial hourly rate by dividing the revenue needed by the average number of hours for each area. This produces an initial rate, which is necessary to produce the revenue needed for each area, assuming the amount of traffic is as expected. We present the calculations for District Two in table 21.</P>
                <GPH SPAN="3" DEEP="81">
                    <GID>EP05AU24.117</GID>
                </GPH>
                <HD SOURCE="HD3">H. Step 8: Calculate Average Weighting Factors by Area</HD>
                <P>In this step, the Coast Guard calculates the average weighting factor for each designated and undesignated area by first collecting the weighting factors, set forth in 46 CFR 401.400, for each vessel trip. Using the weight factor report from SeaPro, we calculate the average weighting factor for each area using the data from each vessel transit from 2014 onward, as shown in tables 22 and 23.</P>
                <BILCOD>BILLING CODE 9110-04-P</BILCOD>
                <GPH SPAN="3" DEEP="640">
                    <PRTPAGE P="63353"/>
                    <GID>EP05AU24.118</GID>
                </GPH>
                <GPH SPAN="3" DEEP="120">
                    <PRTPAGE P="63354"/>
                    <GID>EP05AU24.119</GID>
                </GPH>
                <GPH SPAN="3" DEEP="569">
                    <PRTPAGE P="63355"/>
                    <GID>EP05AU24.120</GID>
                </GPH>
                <GPH SPAN="3" DEEP="250">
                    <PRTPAGE P="63356"/>
                    <GID>EP05AU24.121</GID>
                </GPH>
                <BILCOD>BILLING CODE 9110-04-C</BILCOD>
                <HD SOURCE="HD3">I. Step 9: Calculate Revised Base Rates</HD>
                <P>In this step, we revise the base rates so that the total cost of pilotage will be equal to the revenue needed, after considering the impact of the weighting factors. To do this, we divide the initial base rates calculated in Step 7 by the average weighting factors calculated in Step 8, as shown in table 24.</P>
                <GPH SPAN="3" DEEP="146">
                    <GID>EP05AU24.122</GID>
                </GPH>
                <HD SOURCE="HD3">J. Step 10: Review and Finalize Rates</HD>
                <P>In this step, the Director reviews the base pilotage rates calculated in § 404.109 of this part to ensure it meets the goal of ensuring safe, efficient, and reliable pilotage service. To establish this, the Director considers whether the proposed rates incorporate appropriate compensation for Pilots to handle heavy traffic periods and whether there are enough Pilots to handle those heavy traffic periods. The Director also considers whether the proposed rates would cover operating expenses and infrastructure costs, including average traffic and weighting factors. Based on these considerations, the Director is not proposing any alterations to the rates in this step. We propose to modify § 401.405(a)(3) and (4) to reflect the final rates shown in table 25.</P>
                <GPH SPAN="3" DEEP="204">
                    <PRTPAGE P="63357"/>
                    <GID>EP05AU24.123</GID>
                </GPH>
                <HD SOURCE="HD2">District Three</HD>
                <HD SOURCE="HD3">A. Step 1: Recognize Previous Operating Expenses</HD>
                <P>
                    Step 1 in our ratemaking methodology requires that the Coast Guard review and recognize the previous year's operating expenses (§ 404.101). To do so, we review the independent accountant's financial reports for each association's 2022 expenses and revenues.
                    <SU>29</SU>
                    <FTREF/>
                     For accounting purposes, the financial reports divide expenses into designated and undesignated areas. For costs generally accrued by the pilot associations, such as employee benefits, the cost is divided between the designated and undesignated areas on a pro rata basis. Adjustments have been made by the auditors and are explained in the auditor's reports, which are available in the docket for this rulemaking, where indicated under Section I., Public Participation and Request for Comments.
                </P>
                <FTNT>
                    <P>
                        <SU>29</SU>
                         These reports are available in the docket for this proposed rule.
                    </P>
                </FTNT>
                <P>The recognized operating expenses for District Three are shown in table 26.</P>
                <BILCOD>BILLING CODE 9110-04-P</BILCOD>
                <GPH SPAN="3" DEEP="617">
                    <PRTPAGE P="63358"/>
                    <GID>EP05AU24.124</GID>
                </GPH>
                <GPH SPAN="3" DEEP="619">
                    <PRTPAGE P="63359"/>
                    <GID>EP05AU24.125</GID>
                </GPH>
                <BILCOD>BILLING CODE 9110-04-C</BILCOD>
                <HD SOURCE="HD3">B. Step 2: Project Operating Expenses, Adjusting for Inflation or Deflation</HD>
                <P>
                    In accordance with the text in § 404.102, having identified the recognized 2022 operating expenses in Step 1, the next step is to estimate the current year's operating expenses by adjusting those expenses for inflation 
                    <PRTPAGE P="63360"/>
                    over the 3-year period. We calculate inflation using the BLS data from the CPI for the Midwest Region of the United States for the 2023 inflation rate.
                    <SU>30</SU>
                    <FTREF/>
                     Because the BLS does not provide forecasted inflation data, we use economic projections from the Federal Reserve for the 2024 and 2025 inflation modification.
                    <SU>31</SU>
                    <FTREF/>
                     Based on that information, the calculations for Step 2 are as presented in table 27.
                </P>
                <FTNT>
                    <P>
                        <SU>30</SU>
                         CPI, 
                        <E T="03">supra</E>
                         note 10.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>31</SU>
                         Core PCE, 
                        <E T="03">supra</E>
                         note 11.
                    </P>
                </FTNT>
                <GPH SPAN="3" DEEP="184">
                    <GID>EP05AU24.126</GID>
                </GPH>
                <HD SOURCE="HD3">C. Step 3: Estimate Number of Registered Pilots and Apprentice Pilots</HD>
                <P>
                    In accordance with the text in §  404.103, the Coast Guard estimates the number of fully registered Pilots in each district. In the past, this was done using the staffing model and the process described in §  404.103. Last year, during the 2023 GLPAC meeting, there was a unanimous recommendation by the GLPAC that, after 2024, the Director be given discretion to increase the staffing model plus three Pilots per District, based on industry demand and to ensure shipping reliability.
                    <SU>32</SU>
                    <FTREF/>
                     Additionally, the previous staffing model's maximum are now considered the minimum regarding the number of Pilots needed in each district.
                    <SU>33</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>32</SU>
                         Transcript, 
                        <E T="03">supra</E>
                         note 8, at 89-90.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>33</SU>
                         
                        <E T="03">Id.</E>
                         at 57-58.
                    </P>
                </FTNT>
                <P>We determine the number of fully registered Pilots based on data provided by the WGLPA, as well as the previous mentioned recommendation. We determine the number of Apprentice Pilots based on input from the district on anticipated retirements and staffing needs. These numbers can be found in table 28.</P>
                <GPH SPAN="3" DEEP="95">
                    <GID>EP05AU24.127</GID>
                </GPH>
                <HD SOURCE="HD3">D. Step 4: Determine Target Pilot Compensation Benchmark and Apprentice Pilot Wage Benchmark</HD>
                <P>
                    In this step, we determine the total target Pilot compensation for each area. Because we are issuing an interim ratemaking this year, we follow the procedure outlined in paragraph (b) of § 404.104, which adjusts the existing compensation benchmark by inflation. First, we adjust the 2024 target compensation benchmark of $440,658 by 2.5 percent for a value of $451,674. This accounts for the difference in actual first quarter 2024 ECI inflation, which is 5.1 percent, and the 2024 PCE estimate of 2.6 percent.
                    <E T="51">34 35</E>
                    <FTREF/>
                     The second step accounts for projected inflation from 2024 to 2025, which is 2.2 percent.
                    <SU>36</SU>
                    <FTREF/>
                     Based on the projected 2025 inflation estimate, the proposed target compensation benchmark for 2025 is $461,611 per pilot. The proposed apprentice pilot wage benchmark is 36 percent of the target Pilot compensation, or $166,180 ($461,611 × 0.36).
                </P>
                <FTNT>
                    <P>
                        <SU>34</SU>
                         ECI, 
                        <E T="03">supra</E>
                         note 14.&gt;
                    </P>
                    <P>
                        <SU>35</SU>
                         Median Core PCE Inflation June Projection, 
                        <E T="03">supra</E>
                         note 15.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>36</SU>
                         Median Core PCE Inflation December Projection, 
                        <E T="03">supra</E>
                         note 16.
                    </P>
                </FTNT>
                <P>In accordance with § 404.104(c), we use the revised target individual compensation level to derive the total target Pilot compensation by multiplying the individual target compensation by the estimated number of Registered Pilots for District Three, as shown in table 29. We estimate that the number of Apprentice Pilots needed for District Three in the 2024 season will be one. The total target wages for Apprentice Pilots are allocated with 21 percent for the designated area, and 79 percent for the undesignated areas, in accordance with the allocation for operating expenses.</P>
                <GPH SPAN="3" DEEP="164">
                    <PRTPAGE P="63361"/>
                    <GID>EP05AU24.128</GID>
                </GPH>
                <HD SOURCE="HD3">E. Step 5: Project Working Capital Fund</HD>
                <P>
                    Next, the Coast Guard calculates the working capital fund revenues needed for each area. We first add the figures for projected operating expenses, total target Pilot compensation, and total target Apprentice Pilot wage for each area, and then we find the preceding year's average annual rate of return for new issues of high-grade corporate securities. Using Moody's data, the number is 4.8100 percent, rounded.
                    <SU>37</SU>
                    <FTREF/>
                     By multiplying the two figures, we obtain the working capital fund contribution for each area, as shown in table 30.
                </P>
                <FTNT>
                    <P>
                        <SU>37</SU>
                         Moody's Seasoned Aaa Corporate Bond Yield, 
                        <E T="03">supra</E>
                         note 17.
                    </P>
                </FTNT>
                <GPH SPAN="3" DEEP="146">
                    <GID>EP05AU24.129</GID>
                </GPH>
                <HD SOURCE="HD3">F. Step 6: Project Needed Revenue</HD>
                <P>In this step, the Coast Guard adds all the expenses accrued to derive the total revenue needed for each area. These expenses include the projected operating expenses (from Step 2), the total target Pilot compensation (from Step 4), and the working capital fund contribution (from Step 5). The calculations are shown in table 31.</P>
                <GPH SPAN="3" DEEP="147">
                    <GID>EP05AU24.130</GID>
                </GPH>
                <PRTPAGE P="63362"/>
                <HD SOURCE="HD3">G. Step 7: Calculate Initial Base Rates</HD>
                <P>Having determined the revenue needed for each area in the previous six steps, we divide that number by the expected number of traffic hours to develop an hourly rate.</P>
                <P>
                    Step 7 is a two-part process. The first part is calculating the 10-year traffic average in District Three using the total time on task or Pilot bridge hours. To calculate the time on task for each district, the Coast Guard used billing data from SeaPro. The Coast Guard received revised 2022 bridge hours in the revenue reports submitted by our third-party auditor and has implemented them into the rate in this step of the rulemaking.
                    <SU>38</SU>
                    <FTREF/>
                     Because we calculate separate figures for designated and undesignated waters, there are two parts for each calculation. We show these values in table 32.
                </P>
                <FTNT>
                    <P>
                        <SU>38</SU>
                         See details on the revised figures in Section VII., Regulatory Analyses.
                    </P>
                </FTNT>
                <GPH SPAN="3" DEEP="212">
                    <GID>EP05AU24.131</GID>
                </GPH>
                <P>Next, we derive the initial hourly rate by dividing the revenue needed by the average number of hours for each area. This produces an initial rate, which is necessary to produce the revenue needed for each area, assuming the amount of traffic is as expected. We present the calculations for District Three in table 33.</P>
                <GPH SPAN="3" DEEP="81">
                    <GID>EP05AU24.132</GID>
                </GPH>
                <HD SOURCE="HD3">H. Step 8: Calculate Average Weighting Factors by Area</HD>
                <P>In this step, the Coast Guard calculates the average weighting factor for each designated and undesignated area by first collecting the weighting factors, set forth in 46 CFR 401.400, for each vessel trip. Using the weight factor report from SeaPro, we calculate the average weighting factor for each area using the data from each vessel transit from 2014 onward, as shown in tables 34 and 35. Transits are listed in both the bridge hour report and the weight factor report. For this step, the Coast Guard uses the transits from the weight factor report.</P>
                <BILCOD>BILLING CODE 9110-04-P</BILCOD>
                <GPH SPAN="3" DEEP="640">
                    <PRTPAGE P="63363"/>
                    <GID>EP05AU24.133</GID>
                </GPH>
                <GPH SPAN="3" DEEP="640">
                    <PRTPAGE P="63364"/>
                    <GID>EP05AU24.134</GID>
                </GPH>
                <GPH SPAN="3" DEEP="250">
                    <PRTPAGE P="63365"/>
                    <GID>EP05AU24.135</GID>
                </GPH>
                <GPH SPAN="3" DEEP="422">
                    <PRTPAGE P="63366"/>
                    <GID>EP05AU24.136</GID>
                </GPH>
                <HD SOURCE="HD3">I. Step 9: Calculate Revised Base Rates</HD>
                <P>In this step, we revise the base rates so that the total cost of pilotage will be equal to the revenue needed, after considering the impact of the weighting factors. To do this, we divide the initial base rates calculated in Step 7 by the average weighting factors calculated in Step 8, as shown in table 36.</P>
                <GPH SPAN="3" DEEP="396">
                    <PRTPAGE P="63367"/>
                    <GID>EP05AU24.137</GID>
                </GPH>
                <GPH SPAN="3" DEEP="127">
                    <GID>EP05AU24.138</GID>
                </GPH>
                <HD SOURCE="HD3">J. Step 10: Review and Finalize Rates</HD>
                <P>In this step, the Director reviews the base pilotage rates calculated in § 404.109 of this part to ensure it meets the goal of ensuring safe, efficient, and reliable pilotage service. To establish this, the Director considers whether the proposed rates incorporate appropriate compensation for Pilots to handle heavy traffic periods and whether there are enough Pilots to handle those heavy traffic periods. The Director also considers whether the proposed rates would cover operating expenses and infrastructure costs, including average traffic and weighting factors. Based on these considerations, the Director is not proposing any alterations to the rates in this step. We propose to modify § 401.405(a)(5) and (6) to reflect the proposed rates shown in table 37.</P>
                <GPH SPAN="3" DEEP="114">
                    <PRTPAGE P="63368"/>
                    <GID>EP05AU24.139</GID>
                </GPH>
                <HD SOURCE="HD1">VII. Regulatory Analyses</HD>
                <P>We developed this proposed rule after considering numerous statutes and Executive orders related to rulemaking. A summary of our analyses based on these statutes or Executive orders follows.</P>
                <HD SOURCE="HD2">A. Regulatory Planning and Review</HD>
                <P>Executive Orders 12866 (Regulatory Planning and Review), as amended by Executive Order 14094 (Modernizing Regulatory Review), and 13563 (Improving Regulation and Regulatory Review) direct agencies to assess the costs and benefits of available regulatory alternatives and, if regulation is necessary, to select regulatory approaches that maximize net benefits (including potential economic, environmental, public health and safety effects, distributive impacts, and equity). Executive Order 13563 emphasizes the importance of quantifying costs and benefits, reducing costs, harmonizing rules, and promoting flexibility.</P>
                <P>
                    The Office of Management and Budget (OMB) has not designated this rule a significant regulatory action under section 3(f) of Executive Order 12866, as amended by Executive Order 14094. Accordingly, OMB has not reviewed this regulatory action. The purpose of this proposed rule is to establish new pilotage rates, as 46 U.S.C. 9303(f) requires that rates be established or reviewed and adjusted each year. The statute also requires that base rates be established by a full ratemaking at least once every 5 years, and, in years when base rates are not established, they must be reviewed and, if necessary, adjusted. The Coast Guard concluded the last full ratemaking in February of 2023.
                    <SU>39</SU>
                    <FTREF/>
                     For this NPRM, the Coast Guard estimates an increase in cost of approximately $2.64 million to industry. This is approximately a 7-percent increase because of the change in revenue needed in 2025 compared to the revenue needed in 2024. See table 38.
                </P>
                <FTNT>
                    <P>
                        <SU>39</SU>
                         Great Lakes Pilotage Rates—2023 Annual Ratemaking and Review of Methodology (88 FR 12226), published February 27, 2023.
                    </P>
                </FTNT>
                <GPH SPAN="3" DEEP="327">
                    <PRTPAGE P="63369"/>
                    <GID>EP05AU24.140</GID>
                </GPH>
                <P>In the Great Lakes Pilotage Rates—2024 Annual Review (“2024 final rule”) (89 FR 9038), the Coast Guard used monthly reports for the 2022 bridge hours in Step 7 as provided by the pilot associations. Since that final rule, the Coast Guard received revised estimates of the 2022 bridge hours in the revenue reports submitted by Cohn Reznik. Similarly, the pilot associations were also able to provide updated 2022 monthly reports in April 2024. For this proposed rule, the Coast Guard revises the bridge hours for 2022 in Step 7, using the latest available information. This revision ensures that all figures are comparable, since the initial monthly reports and weight factor reports received for the 2024 final rule showed different totals for bridge hours.</P>
                <P>Table 39 shows the difference between the 2022 bridge hour figures as published in the 2024 final rule, and the revised figures as of this proposed rule.</P>
                <GPH SPAN="3" DEEP="170">
                    <GID>EP05AU24.141</GID>
                </GPH>
                <P>Similarly, the Coast Guard received updated 2022 weight factor reports in April 2024. The Coast Guard uses the latest available information to revise the number of transits by vessel class in Step 8, “Calculate average weighting factors by Area”. Table 40 shows the difference between the 2022 transit figures as published in the 2024 final rule, and the revised figures as of this proposed rule.</P>
                <BILCOD>BILLING CODE 9110-04-P</BILCOD>
                <GPH SPAN="3" DEEP="519">
                    <PRTPAGE P="63370"/>
                    <GID>EP05AU24.142</GID>
                </GPH>
                <BILCOD>BILLING CODE 9110-04-C</BILCOD>
                <P>The Coast Guard is required to review and adjust pilotage rates on the Great Lakes annually. See Section III., Basis and Purpose, of this preamble for detailed discussions of the legal basis and purpose for this rulemaking. Based on our annual review for this rulemaking, we are adjusting the pilotage rates in 2025 to generate sufficient revenues for each district to reimburse its necessary and reasonable operating expenses, to fairly compensate properly trained and rested Pilots, and to provide an appropriate working capital fund to use for improvements. The result would be an increase in rates for both areas in District One, the designated area for District Two, and the undesignated area in District Three. The result would be a decrease in rates for the undesignated area for District Two and the designated area for District Three. These changes would also lead to a net increase in the cost of service to shippers. The change in per-unit cost to each individual shipper would depend on their area of operation.</P>
                <P>A detailed discussion of our economic impact analysis follows.</P>
                <HD SOURCE="HD3">Affected Population</HD>
                <P>
                    This proposed rule affects United States Great Lakes Pilots and Apprentice Pilots, the 3 pilot associations, and the owners and operators of 280 oceangoing vessels that transit the Great Lakes annually on average from 2021 to 2023. The Coast Guard estimates that there will be 61 Registered Pilots and 3 Apprentice Pilots during 2025. The shippers affected by these rate changes 
                    <PRTPAGE P="63371"/>
                    are those owners and operators of domestic vessels operating “on register” (engaged in foreign trade) and the owners and operators of non-Canadian foreign vessels on routes within the Great Lakes system. These owners and operators must have Pilots or pilotage service as required by 46 U.S.C. 9302. There is no minimum tonnage limit or exemption for these vessels. The statute applies only to commercial vessels, not to recreational vessels. United States-flagged vessels not operating on register, and Canadian “lakers,” which account for most commercial shipping on the Great Lakes, are not required by 46 U.S.C. 9302 to have pilots. However, these United States- and Canadian-flagged lakers may voluntarily choose to engage a Great Lakes Registered Pilot. Vessels that are U.S.-flagged may opt to have a Pilot for varying reasons, such as unfamiliarity with designated waters and ports, or for insurance purposes.
                </P>
                <P>The Coast Guard used billing information from the years 2021 through 2023 from SeaPro to estimate the average annual number of vessels affected by the rate adjustment. SeaPro tracks data related to managing and coordinating the dispatch of Pilots on the Great Lakes, and billing in accordance with the services. As described in Step 7 of the ratemaking methodology, we use a 10-year average to estimate the traffic. We used 3 years of the most recent billing data to estimate the affected population. We believe that using 3 years of billing data is a better representation of the vessel population currently using pilotage services and impacted by this proposed rule.</P>
                <P>We found that 484 unique vessels used pilotage services during the years 2021 through 2023. That is, these vessels had a Pilot dispatched to the vessel, and billing information was recorded in SeaPro. Of these vessels, 451 were foreign-flagged vessels and 33 were U.S.-flagged vessels. As stated previously, U.S.-flagged vessels not operating on register are not required to have a Registered Pilot, per 46 U.S.C. 9302, but can voluntarily choose to have one.</P>
                <P>
                    Numerous factors affect vessel traffic, which varies from year to year. Therefore, rather than using the total number of vessels over the time period, the Coast Guard took an average of the unique vessels using pilotage services from the years 2021 through 2023 as the best representation of vessels estimated to be affected by the rates in this proposed rule. From 2021 through 2023, an average of 280 vessels used pilotage services annually.
                    <SU>40</SU>
                    <FTREF/>
                     On average, 268 of these vessels were foreign-flagged, and 13 were U.S.-flagged vessels that voluntarily opted into the pilotage service (these figures are rounded averages).
                </P>
                <FTNT>
                    <P>
                        <SU>40</SU>
                         Some vessels entered the Great Lakes multiple times in a single year, affecting the average number of unique vessels using pilotage services in any given year.
                    </P>
                </FTNT>
                <HD SOURCE="HD3">Total Cost to Shippers</HD>
                <P>The rate changes resulting from this adjustment to the rates would result in a net increase in the cost of service to shippers. However, the change in per-unit cost to each individual shipper would be dependent on their area of operation.</P>
                <P>The Coast Guard estimates the effect of the rate changes on shippers by comparing the total projected revenues needed to cover costs in 2024 with the total projected revenues to cover costs in 2025. We set pilotage rates so that pilot associations receive enough revenue to cover their necessary and reasonable expenses. Shippers pay these rates when they engage a Pilot, as required by 46 U.S.C. 9302. Therefore, the aggregate payments of shippers to pilot associations are equal to the projected necessary revenues for pilot associations. The revenues each year represent the total costs that shippers must pay for pilotage services. The change in revenue from the previous year is the additional cost to shippers discussed in this proposed rule.</P>
                <P>The impacts of the rate changes on shippers are estimated from the district pilotage projected revenues (shown in tables 7, 19, and 31 of this preamble). The Coast Guard estimates that, for 2025, the projected revenue needed for all three districts is $42,920,634.</P>
                <P>
                    To estimate the change in cost to shippers from this proposed rule, the Coast Guard compared the 2025 total projected revenues to the 2024 projected revenues. Because we review and prescribe rates for Great Lakes pilotage annually, the effects are estimated as a single-year cost rather than annualized over a 10-year period. In the 2024 final rule, we estimated the total projected revenue needed for 2024 as $40,280,666.
                    <SU>41</SU>
                    <FTREF/>
                     This is the best approximation of 2024 revenues, as, at the time of publication of this proposed rule, the Coast Guard does not have enough audited data available for 2024 to revise these projections. Table 41 shows the revenue projections for 2024 and 2025 and details the additional cost increases to shippers by area and district as a result of the rate changes on traffic in Districts One, Two, and Three.
                </P>
                <FTNT>
                    <P>
                        <SU>41</SU>
                         2024 Final Rule, 89 FR at 9066 (Table 43).
                    </P>
                </FTNT>
                <GPH SPAN="3" DEEP="186">
                    <GID>EP05AU24.143</GID>
                </GPH>
                <PRTPAGE P="63372"/>
                <P>The resulting difference between the projected revenue in 2024 and the projected revenue in 2025 is the annual change in payments from shippers to pilots as a result of the rate changes proposed by this NPRM. The effect of the rate changes to shippers would vary by area and district. After considering the change in pilotage rates, the proposed rate changes would lead to affected shippers operating in District One experiencing an increase in payments of $936,031 over the previous year. Affected shippers operating in District Two and District Three would experience an increase in payments of $986,893 and $717,044, respectively, when compared with 2024. The overall adjustment in payments would increase payments by shippers of $2,639,968 across all three districts (a 7-percent increase when compared with 2024). Again, because the Coast Guard reviews and sets rates for Great Lakes pilotage annually, we estimate the impacts as single-year costs, rather than annualizing them over a 10-year period.</P>
                <P>
                    Table 42 shows the difference in revenue by revenue-component from 2024 to 2025 and presents each revenue-component as a percentage of the total revenue needed. In both 2024 and 2025, the largest revenue-component was target pilotage compensation (63 percent of total revenue needed in 2024, and 66 percent of total revenue needed in 2025), followed by operating expenses (30 percent of total revenue needed in 2024, and 29 percent of total revenue needed in 2025). The large increase in the working capital fund, 25 percent from 2024 to 2025, is driven by an increase in the Target Rate of Return on Investment, from 4.0742 percent in 2022 to 4.8100 percent in 2023.
                    <SU>42</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>42</SU>
                         Moody's Seasoned Aaa Corporate Bond Yield, 
                        <E T="03">supra</E>
                         note 17.
                    </P>
                </FTNT>
                <BILCOD>BILLING CODE 9110-04-P</BILCOD>
                <GPH SPAN="3" DEEP="636">
                    <PRTPAGE P="63373"/>
                    <GID>EP05AU24.144</GID>
                </GPH>
                <BILCOD>BILLING CODE 9110-04-C</BILCOD>
                <P>
                    As stated above, we estimate that there would be a total increase in revenue of $2,639,968 needed by the pilot associations. This represents an increase in revenue needed for target Pilot compensation of $2,600,107, a 
                    <PRTPAGE P="63374"/>
                    decrease in revenue needed for the total Apprentice Pilot wage benchmark of ($453,282), an increase in the revenue needed for adjusted operating expenses of $100,275, and an increase in the revenue needed for the working capital fund of $392,868.
                </P>
                <P>
                    The change in revenue needed for Pilot compensation, $2,600,107, is due to three factors: (1) The changes to adjust 2024 pilotage compensation to account for the difference between actual ECI inflation 
                    <SU>43</SU>
                    <FTREF/>
                     (5.1 percent) and predicted PCE inflation 
                    <SU>44</SU>
                    <FTREF/>
                     (2.6 percent) for 2024; (2) projected inflation of pilotage compensation in Step 2 of the methodology, using predicted inflation through 2025; 
                    <SU>45</SU>
                    <FTREF/>
                     and (3) an increase of three authorized Pilots.
                </P>
                <FTNT>
                    <P>
                        <SU>43</SU>
                         ECI, 
                        <E T="03">supra</E>
                         note 14.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>44</SU>
                         Median Core PCE Inflation June Projection, 
                        <E T="03">supra</E>
                         note 15.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>45</SU>
                         Median Core PCE Inflation December Projection, 
                        <E T="03">supra</E>
                         note 16.
                    </P>
                </FTNT>
                <P>The target compensation is $461,611 per Pilot in 2025, compared to $440,658 in 2024. The proposed changes to modify the 2024 Pilot compensation to account for the difference between predicted and actual inflation would increase the 2024 target compensation value by 2.5 percent. As shown in table 43, this inflation adjustment increases total compensation by $11,016 per Pilot, and the total revenue needed by $672,003, when accounting for all 61 Pilots.</P>
                <GPH SPAN="3" DEEP="220">
                    <GID>EP05AU24.145</GID>
                </GPH>
                <P>Similarly, table 44 shows the impact of the difference between predicted and actual inflation on the target Apprentice Pilot compensation benchmark. The inflation adjustment increases the compensation benchmark by $3,966 per Apprentice Pilot, and the total revenue needed by $11,898 when accounting for all three Apprentice Pilots.</P>
                <GPH SPAN="3" DEEP="220">
                    <GID>EP05AU24.146</GID>
                </GPH>
                <PRTPAGE P="63375"/>
                <P>The Coast Guard predicts that 61 Pilots would be needed for the 2025 season. This is an increase of three Pilots from the 2024 season. Table 45 shows the increase of $1,351,784 in revenue needed for Pilot compensation. To avoid double counting, this value excludes the change in revenue resulting from the change to adjust 2024 Pilot compensation to account for the difference between actual and predicted inflation.</P>
                <GPH SPAN="3" DEEP="286">
                    <GID>EP05AU24.147</GID>
                </GPH>
                <P>Similarly, the Coast Guard predicts that three Apprentice Pilots would be needed for the 2025 season. This would be a decrease of three Apprentice Pilots from the 2024 season. Table 46 shows the decrease of ($486,642) in revenue needed solely for Apprentice Pilot compensation. As noted previously, to avoid double counting, this value excludes the change in revenue resulting from the change to adjust 2024 Apprentice Pilot compensation to account for the difference between actual and predicted inflation.</P>
                <GPH SPAN="3" DEEP="296">
                    <PRTPAGE P="63376"/>
                    <GID>EP05AU24.148</GID>
                </GPH>
                <P>Another increase, $606,130, would be the result of increasing compensation for the 61 Pilots, to account for future inflation of 2.2 percent in 2025. This would increase total compensation by $9,937 per Pilot, as shown in table 47.</P>
                <GPH SPAN="3" DEEP="153">
                    <GID>EP05AU24.149</GID>
                </GPH>
                <P>Similarly, an increase of $10,732 would be the result of increasing compensation for the three Apprentice Pilots, to account for future inflation of 2.2 percent in 2025. This would increase total compensation by $3,577 per Apprentice Pilot, as shown in table 48.</P>
                <GPH SPAN="3" DEEP="162">
                    <PRTPAGE P="63377"/>
                    <GID>EP05AU24.150</GID>
                </GPH>
                <P>
                    Table 49
                    <FTREF/>
                     presents the percentage change in revenue by area and revenue-component, excluding surcharges, as they are applied at the district level.
                    <SU>46</SU>
                </P>
                <FTNT>
                    <P>
                        <SU>46</SU>
                         The 2024 projected revenues are from the Great Lakes Pilotage Rate—2024 Annual Review and Revisions to Methodology final rule (89 FR 9038), tables 11, 23, and 35. The 2025 projected revenues are from tables 7, 19, and 31 of this proposed rule.
                    </P>
                </FTNT>
                <BILCOD>BILLING CODE 9110-04-P</BILCOD>
                <GPH SPAN="3" DEEP="620">
                    <PRTPAGE P="63378"/>
                    <GID>EP05AU24.151</GID>
                </GPH>
                <BILCOD>BILLING CODE 9110-04-C</BILCOD>
                <HD SOURCE="HD3">Benefits</HD>
                <P>
                    This proposed rule allows the Coast Guard to meet the requirements in 46 U.S.C. 9303 to review the rates for pilotage services on the Great Lakes. The rate changes promote safe, efficient, and reliable pilotage service on the Great Lakes by (1) ensuring that rates 
                    <PRTPAGE P="63379"/>
                    cover an association's operating expenses; (2) providing fair Pilot compensation, adequate training, and sufficient rest periods for Pilots; and (3) ensuring that pilot associations produce enough revenue to fund future improvements. The rate changes also help recruit and retain Pilots, which ensures enough Pilots to meet peak shipping demand, helping to reduce delays caused by Pilot shortages.
                </P>
                <HD SOURCE="HD2">B. Small Entities</HD>
                <P>Under the Regulatory Flexibility Act, 5 U.S.C. 601-612, we have considered whether this proposed rule would have a significant economic impact on a substantial number of small entities. The term “small entities” comprises small businesses, not-for-profit organizations that are independently owned and operated and are not dominant in their fields, and governmental jurisdictions with populations of less than 50,000.</P>
                <P>
                    For this proposed rule, the Coast Guard reviewed recent company size and ownership data for the vessels identified in SeaPro, and we reviewed business revenue and size data provided by publicly available sources such as ReferenceUSA.
                    <SU>47</SU>
                    <FTREF/>
                     As described in Section VII., Regulatory Analyses, of this preamble, we found that 484 unique vessels used pilotage services during the years 2021 through 2023. These vessels are owned by 63 entities, of which 49 are foreign entities that operate primarily outside the United States, and the remaining 14 entities are U.S. entities. We compared the revenue and employee data found in the company search to the Small Business Administration's (SBA) small business threshold, as defined in the SBA's “Table of Size Standards” for small businesses, to determine how many of these companies are considered small entities.
                    <SU>48</SU>
                    <FTREF/>
                     Table 50 shows the North American Industry Classification System (NAICS) codes of the U.S. entities and the small entity standard size established by the SBA.
                </P>
                <FTNT>
                    <P>
                        <SU>47</SU>
                         
                        <E T="03">See Resources for Reference Solutions Users,</E>
                         ReferenceUSA, 
                        <E T="03">https://resource.referenceusa.com/</E>
                         (last accessed 04/22/2024).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>48</SU>
                         
                        <E T="03">See Table of Size Standards, https://www.sba.gov/document/support--table-size-standards</E>
                         (Last visited 5/01/24). SBA has established a “Table of Size Standards” for small businesses that sets small business size standards by NAICS code. A size standard, which is usually stated in number of employees or average annual receipts (“revenues”), represents the largest size that a business (including its subsidiaries and affiliates) may be in order to remain classified as a small business for SBA and Federal contracting programs.
                    </P>
                </FTNT>
                <GPH SPAN="3" DEEP="203">
                    <GID>EP05AU24.152</GID>
                </GPH>
                <P>Of the 14 U.S. entities, four exceed the SBA's small business standards for small entities. To estimate the potential impact on the remaining 10 small entities, the Coast Guard used their 2023 invoice data to estimate their pilotage costs in 2025. We increased their 2023 costs to account for the changes in pilotage rates resulting from this proposed rule and the 2024 final rule. We estimated the change in cost to these entities resulting from this proposed rule by subtracting their estimated 2024 pilotage costs from their estimated 2025 pilotage costs and found the average costs to small firms would be approximately $12,510, with a range of $1,294 to $39,146. We then compared the estimated change in pilotage costs between 2024 and 2025 with each firm's annual revenue. In all but one case, the impact of the change in estimated pilotage expenses would be below 1 percent of revenues. For one entity, the impact would be 6.33 percent of revenues.</P>
                <P>In addition to the owners and operators discussed previously, three U.S. entities that receive revenue from pilotage services would be affected by this proposed rule. These are the three pilot associations that provide and manage pilotage services within the Great Lakes districts. District One, “St. Lawrence Seaway Pilots Association” uses the NAICS code “Inland Water Freight Transportation” with a small-entity size standard of 1,050 employees. District Two, “Lakes Pilots Association” uses the NAICS code, “Business Associations” with a small-entity size standard of $15,500,000 in revenue. District Three, “Western Great Lakes Pilots Association” did not have a registered NAICS code through ReferenceUSA. All three associations are considered small entities.</P>
                <P>Finally, the Coast Guard did not find any small not-for-profit organizations that are independently owned and operated and are not dominant in their fields that would be impacted by this proposed rule. We also did not find any small governmental jurisdictions with populations of fewer than 50,000 people that would be impacted by this proposed rule. Based on this analysis, we conclude this proposed rule would not have a significant economic impact on a substantial number of small entities.</P>
                <P>
                    Therefore, the Coast Guard certifies under 5 U.S.C. 605(b) that this proposed 
                    <PRTPAGE P="63380"/>
                    rule would not have a significant economic impact on a substantial number of small entities. If you think that your business, organization, or governmental jurisdiction qualifies as a small entity and that this proposed rule would have a significant economic impact on it, please submit a comment to the docket at the address listed in the Public Participation and Request for Comments section of this preamble. In your comment, explain why you think it qualifies and how and to what degree this proposed rule would economically affect it.
                </P>
                <P>The Coast Guard is unable to offer any meaningful alternatives to this proposed rule. Under 46 U.S.C. 9303, the Coast Guard is required to prescribe these rates via regulation and therefore cannot identify any significant alternatives which “accomplish the stated objectives of the applicable statutes” (5 U.S.C. 603(c)).</P>
                <HD SOURCE="HD2">C. Assistance for Small Entities</HD>
                <P>
                    Under section 213(a) of the Small Business Regulatory Enforcement Fairness Act of 1996, Public Law 104-121, we want to assist small entities in understanding this proposed rule so that they can better evaluate its effects on them and participate in the rulemaking. 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 call or email the person in the 
                    <E T="02">FOR FURTHER INFORMATION CONTACT</E>
                     section of this proposed rule. The Coast Guard will not retaliate against small entities that question or complain about this proposed rule or any policy or action of the Coast Guard.
                </P>
                <P>Small businesses may send comments on the actions of Federal employees who enforce, or otherwise determine compliance with, Federal regulations to the Small Business and Agriculture Regulatory Enforcement Ombudsman and the Regional Small Business Regulatory Fairness Boards. The Ombudsman evaluates these actions annually and rates each agency's responsiveness to small business. If you wish to comment on actions by employees of the Coast Guard, call 1-888-REG-FAIR (1-888-734-3247).</P>
                <HD SOURCE="HD2">D. Collection of Information</HD>
                <P>This proposed rule would call for no new collection of information under the Paperwork Reduction Act of 1995, 44 U.S.C. 3501-3520.</P>
                <HD SOURCE="HD2">E. Federalism</HD>
                <P>A rule has implications for federalism under Executive Order 13132 (Federalism) if it has a substantial direct effect on States, on the relationship between the National Government and the States, or on the distribution of power and responsibilities among the various levels of government. We have analyzed this proposed rule under Executive Order 13132 and have determined that it is consistent with the fundamental federalism principles and preemption requirements described in Executive Order 13132. Our analysis follows.</P>
                <P>Congress directed the Coast Guard to establish “rates and charges for pilotage services.” 46 U.S.C. 9303(f). This proposed regulation is issued pursuant to that statute and is preemptive of State law as specified in 46 U.S.C. 9306. Under 46 U.S.C. 9306, a “State or political subdivision of a State may not regulate or impose any requirement on pilotage on the Great Lakes.” As a result, States or local governments are expressly prohibited from regulating within this category. Therefore, this proposed rule is consistent with the fundamental federalism principles and preemption requirements described in Executive Order 13132.</P>
                <P>
                    While it is well settled that States may not regulate in categories in which Congress intended the Coast Guard to be the sole source of a vessel's obligations, the Coast Guard recognizes the key role that State and local governments may have in making regulatory determinations. Additionally, for rules with federalism implications and preemptive effect, Executive Order 13132 specifically directs agencies to consult with State and local governments during the rulemaking process. If you believe this proposed rule would have implications for federalism under Executive Order 13132, please call or email the person listed in the 
                    <E T="02">FOR FURTHER INFORMATION CONTACT</E>
                     section of this preamble.
                </P>
                <HD SOURCE="HD2">F. Unfunded Mandates</HD>
                <P>The Unfunded Mandates Reform Act of 1995, 2 U.S.C. 1531-1538, requires Federal agencies to assess the effects of their discretionary regulatory actions. In particular, the Act addresses actions that may result in the expenditure by a State, local, or tribal government, in the aggregate, or by the private sector of $100 million (adjusted for inflation) or more in any one year. Although this proposed rule would not result in such an expenditure, we do discuss the potential effects of this proposed rule elsewhere in this preamble.</P>
                <HD SOURCE="HD2">G. Taking of Private Property</HD>
                <P>This proposed rule would not cause a taking of private property or otherwise have taking implications under Executive Order 12630 (Governmental Actions and Interference with Constitutionally Protected Property Rights).</P>
                <HD SOURCE="HD2">H. Civil Justice Reform</HD>
                <P>This proposed rule meets applicable standards in sections 3(a) and 3(b)(2) of Executive Order 12988, (Civil Justice Reform), to minimize litigation, eliminate ambiguity, and reduce burden.</P>
                <HD SOURCE="HD2">I. Protection of Children</HD>
                <P>We have analyzed this proposed rule under Executive Order 13045 (Protection of Children from Environmental Health Risks and Safety Risks). This proposed rule is not an economically significant rule and would not create an environmental risk to health or risk to safety that might disproportionately affect children.</P>
                <HD SOURCE="HD2">J. Indian Tribal Governments</HD>
                <P>This proposed rule does not have tribal implications under Executive Order 13175 (Consultation and Coordination with Indian Tribal Governments), because it would 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">K. Energy Effects</HD>
                <P>We have analyzed this proposed rule under Executive Order 13211 (Actions Concerning Regulations That Significantly Affect Energy Supply, Distribution, or Use). We have determined that it is not a “significant energy action” under that order because it is not a “significant regulatory action” under Executive Order 12866 and is not likely to have a significant adverse effect on the supply, distribution, or use of energy.</P>
                <HD SOURCE="HD2">L. Technical Standards</HD>
                <P>
                    The National Technology Transfer and Advancement Act, codified as a note to 15 U.S.C. 272, directs agencies to use voluntary consensus standards in their regulatory activities unless the agency provides Congress, through OMB, with an explanation of why using these standards would be inconsistent with applicable law or otherwise impractical. Voluntary consensus standards are technical standards (
                    <E T="03">e.g.,</E>
                     specifications of materials, performance, design, or operation; test methods; sampling procedures; and related management systems practices) that are 
                    <PRTPAGE P="63381"/>
                    developed or adopted by voluntary consensus standards bodies.
                </P>
                <P>This proposed rule does not use technical standards. Therefore, we did not consider the use of voluntary consensus standards.</P>
                <HD SOURCE="HD2">M. Environment</HD>
                <P>We have analyzed this proposed rule under Department of Homeland Security Management Directive 023-01, Rev. 1, associated implementing instructions, and Environmental Planning COMDTINST 5090.1 (series), which guide the Coast Guard in complying with the National Environmental Policy Act of 1969 (42 U.S.C. 4321-4370f), and have made a preliminary determination that this action is one of a category of actions that do not individually or cumulatively have a significant effect on the human environment. A preliminary Record of Environmental Consideration supporting this determination is available in the docket. For instructions on locating the docket, see the Public Participation and Request for Comments section of this preamble. This proposed rule would be categorically excluded under paragraphs A3 and L54 of Appendix A, Table 1 of the Department of Homeland Security (DHS) Instruction Manual 023-01-001-01, Rev. 1. Paragraph A3 pertains to the promulgation of rules of the following nature: (a) those of a strictly administrative or procedural nature; (b) those that implement, without substantive change, statutory or regulatory requirements; (c) those that implement, without substantive change, procedures, manuals, and other guidance documents; (d) those that interpret or amend an existing regulation without changing its environmental effect; (e) those that provide technical guidance on safety and security matters; and (f) those that provide guidance for the preparation of security plans. Paragraph L54 pertains to regulations which are editorial or procedural.</P>
                <P>This proposed rule involves adjusting the pilotage rates for 2025 to account for changes in district operating expenses, changes in the number of pilots, and anticipated inflation. All changes are consistent with the Coast Guard's maritime safety missions. We seek any comments or information that may lead to the discovery of a significant environmental impact from this proposed rule.</P>
                <LSTSUB>
                    <HD SOURCE="HED">List of Subjects in 46 CFR Part 401</HD>
                    <P>Administrative practice and procedure, Great Lakes; Navigation (water), Penalties, Reporting and recordkeeping requirements, Seamen.</P>
                </LSTSUB>
                <P>For the reasons discussed in the preamble, the Coast Guard proposes to amend 46 CFR part 401 as follows:</P>
                <PART>
                    <HD SOURCE="HED">PART 401—GREAT LAKES PILOTAGE REGULATIONS</HD>
                </PART>
                <AMDPAR>1. The authority citation for part 401 is revised to read as follows:</AMDPAR>
                <AUTH>
                    <HD SOURCE="HED">Authority:</HD>
                    <P> 46 U.S.C. 2103, 2104(a), 6101, 7701, 8105, 9303, 9304; DHS Delegation No. 00170.1, Revision No. 01.4, paragraphs (II)(92)(a), (d), (e), (f).</P>
                </AUTH>
                <AMDPAR>2. Amend § 401.405 by revising paragraphs (a)(1) through (6) to read as follows:</AMDPAR>
                <SECTION>
                    <SECTNO>§ 401.405</SECTNO>
                    <SUBJECT>Pilotage rates and charges.</SUBJECT>
                    <P>(a) * * *</P>
                    <P>(1) The St. Lawrence River is $981;</P>
                    <P>(2) Lake Ontario is $640;</P>
                    <P>(3) Lake Erie is $573;</P>
                    <P>(4) The navigable waters from Southeast Shoal to Port Huron, MI is $748;</P>
                    <P>(5) Lakes Huron, Michigan, and Superior is $438; and</P>
                    <P>(6) The St. Marys River is $821.</P>
                    <STARS/>
                </SECTION>
                <SIG>
                    <DATED> Dated: July 29, 2024.</DATED>
                    <NAME>W.R. Arguin,</NAME>
                    <TITLE>Rear Admiral, U.S. Coast Guard, Assistant Commandant for Prevention Policy.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17028 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 9110-04-P</BILCOD>
        </PRORULE>
        <PRORULE>
            <PREAMB>
                <AGENCY TYPE="N">FEDERAL COMMUNICATIONS COMMISSION</AGENCY>
                <CFR>47 CFR Parts 25, 73, and 76</CFR>
                <DEPDOC>[MB Docket No. 24-211; FCC 24-74; FR ID 235498]</DEPDOC>
                <SUBJECT>Disclosure and Transparency of Artificial Intelligence-Generated Content in Political Advertisements</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Federal Communications Commission.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Proposed rule.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>In this document, the Federal Communications Commission (Commission or FCC) initiates a proceeding to provide greater transparency regarding the use of artificial intelligence-generated content in political advertising. Specifically, the Commission proposes to require radio and television broadcast stations; cable operators, Direct Broadcast Satellite (DBS) providers, and Satellite Digital Audio Radio Service (SDARS) licensees engaged in origination programming; and permit holders transmitting programming pursuant to section 325(c) of the Communications Act of 1934 (Act), to provide an on-air announcement for all political ads (including both candidate ads and issue ads) that contain artificial intelligence (AI)-generated content disclosing the use of such content in the ad. The Commission also propose to require these licensees and regulatees to include a notice in their online political files for all political ads that include AI-generated content disclosing that the ad contains such content.</P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Comments for this proceeding are due on or before September 4, 2024; reply comments are due on or before September 19, 2024.</P>
                </EFFDATE>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>You may submit comments, identified by MB Docket No. 24-211, by any of the following methods:</P>
                    <P>
                          
                        <E T="03">Federal Communications Commission's website: https://www.fcc.gov/cgb/ecfs/.</E>
                         Follow the instructions for submitting comments.
                    </P>
                    <P>
                          
                        <E T="03">Mail:</E>
                         Filings can be sent by hand or messenger delivery, by commercial overnight courier, or by first-class or overnight U.S. Postal Service mail (although the Commission continues to experience delays in receiving U.S. Postal Service mail). All filings must be addressed to the Commission's Secretary, Office of the Secretary, Federal Communications Commission.
                    </P>
                    <P>
                          
                        <E T="03">People with Disabilities:</E>
                         Contact the FCC to request reasonable accommodations (accessible format documents, sign language interpreters, CART, etc.) by email: 
                        <E T="03">FCC504@fcc.gov</E>
                         or phone: (202) 418-0530 or TTY: (202) 418-0432.
                    </P>
                    <P>
                        For detailed instructions for submitting comments and additional information on the rulemaking process, see the 
                        <E T="02">SUPPLEMENTARY INFORMATION</E>
                         section of this document.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        For additional information, contact Kathy Berthot, 
                        <E T="03">Kathy.Berthot@fcc.gov,</E>
                         of the Media Bureau, Policy Division, (202) 418-7454.
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    This is a summary of the Commission's Notice of Proposed Rulemaking (NPRM), FCC 24-74, adopted on July 10, 2024, and released on July 25, 2024. The full text is available for public inspection and copying during regular business hours in the FCC Reference Center, Federal Communications Commission, 445 12th Street SW, CY-A257, Washington, DC 20554. This document will also be available via ECFS (
                    <E T="03">http://www.fcc.gov/cgb/ecfs/</E>
                    ). Documents will be available electronically in ASCII, Word 97, and/or Adobe Acrobat. Alternative formats are available for people with disabilities 
                    <PRTPAGE P="63382"/>
                    (Braille, large print, electronic files, audio format), by sending an email to 
                    <E T="03">fcc504@fcc.gov</E>
                     or calling the Commission's Consumer and Governmental Affairs Bureau at (202) 418-0530 (voice), (202) 418-0432 (TTY).
                </P>
                <P>Pursuant to §§ 1.415 and 1.419 of the Commission's rules, 47 CFR 1.415, 1.419, interested parties may file comments and reply comments on or before the dates indicated on the first page of this document. Comments may be filed using the Commission's Electronic Comment Filing System (ECFS).</P>
                <P>
                    • 
                    <E T="03">Electronic Filers:</E>
                     Comments may be filed electronically using the internet by accessing the ECFS: 
                    <E T="03">https://www.fcc.gov/ecfs/.</E>
                </P>
                <P>
                    • 
                    <E T="03">Paper Filers:</E>
                     Parties who choose to file by paper must file an original and one copy of each filing.
                </P>
                <P>• Filings can be sent by hand or messenger delivery, by commercial courier, or by the U.S. Postal Service. All filings must be addressed to the Secretary, Federal Communications Commission.</P>
                <P>• Hand-delivered or messenger-delivered paper filings for the Commission's Secretary are accepted between 8 a.m. and 4 p.m. by the FCC's mailing contractor at 9050 Junction Drive, Annapolis Junction, MD 20701. All hand deliveries must be held together with rubber bands or fasteners. Any envelopes and boxes must be disposed of before entering the building.</P>
                <P>• Commercial courier deliveries (any deliveries not by the U.S. Postal Service) must be sent to 9050 Junction Drive, Annapolis Junction, MD 20701.</P>
                <P>• Filings sent by U.S. Postal Service First-Class Mail, Priority Mail, and Priority Mail Express must be sent to 45 L Street NE, Washington, DC 20554.</P>
                <P>
                    <E T="03">People with Disabilities:</E>
                     To request materials in accessible formats for people with disabilities (braille, large print, electronic files, audio format), send an email to 
                    <E T="03">fcc504@fcc.gov</E>
                     or call the Consumer &amp; Governmental Affairs Bureau at 202-418-0530 (voice), 202-418-0432 (TTY).
                </P>
                <P>
                    <E T="03">Paperwork Reduction Act of 1995 Analysis:</E>
                     This document proposes new or modified information collection requirements. The Commission, as part of its continuing effort to reduce paperwork burdens and pursuant to the Paperwork Reduction Act of 1995, Public Law 104-13, invites the general public and the Office of Management and Budget (OMB) to comment on these information collection requirements. In addition, pursuant to the Small Business Paperwork Relief Act of 2002, Public Law 107-198, see 44 U.S.C. 3506(c)(4), the Commission seeks specific comment on how it might further reduce the information collection burden for small business concerns with fewer than 25 employees.
                </P>
                <P>
                    <E T="03">Providing Accountability Through Transparency Act:</E>
                     Consistent with the Providing Accountability Through Transparency Act, Public Law 118-9, a summary of this document will be available on: 
                    <E T="03">https://www.fcc.gov/</E>
                    proposed-rulemakings.
                </P>
                <HD SOURCE="HD1">Synopsis</HD>
                <P>1. Recognizing the potentially beneficial use of AI in political advertisements while keeping in mind broadcasters and other regulated entities' statutory obligation to serve the public interest by taking responsibility for material—including false, misleading or deceptive material—disseminated to the public through their facilities, the Commission initiates the NPRM to provide greater transparency regarding the use of AI-generated content in political advertising. Specifically, the Commission proposes to require radio and television broadcast stations; cable operators, DBS providers, and SDARS licensees engaged in origination programming; and permit holders transmitting programming pursuant to section 325(c) of the Act, to provide an on-air announcement for all political ads that include AI-generated content disclosing the use of such content in the ad. The Commission also proposes to require these licensees and regulatees to include a notice in their online political files for all political ads that include AI-generated content disclosing that the ad contains such content. To be clear, the Commission is not proposing to ban or otherwise restrict the use of AI-generated content in political ads. Rather, it is simply seeking to ensure that listeners and viewers are informed when political ads include such content so that the public can evaluate such ads for themselves.</P>
                <HD SOURCE="HD1">The FCC's Role</HD>
                <P>2. The presentation of political programming is considered an essential element of broadcasters' obligation to serve the public interest because of the critical role such programming plays in fostering an informed electorate, which in turn is vital to the effective operation of the democratic process. In keeping with this critical role, the political programming and recordkeeping requirements established by Congress and implemented by the Commission ensure that candidates for elective office have access to broadcast facilities and certain other media platforms and promote transparency about the entities that sponsor political ads. Further, the Commission has long recognized that broadcasters “must assume responsibility for all material which is broadcast through their facilities,” “includ[ing] all programs and advertising material which they present to the public,” and “to take all reasonable measures to eliminate any false, misleading, or deceptive matter” and that “[t]his duty is personal to the licensee and may not be delegated.”</P>
                <P>
                    3. 
                    <E T="03">Political Programming Requirements.</E>
                     The relevant statutory political programming provisions applicable to broadcasters are set forth in sections 315 and 312(a)(7) of the Communications Act of 1934, as amended (Act). Under section 315(a), if a broadcast licensee permits one legally qualified candidate for a public office to use its station, it must afford all other candidates for that office an “equal opportunity” to use the station. In addition, section 315(a) prohibits broadcast licensees from censoring candidate ads. The equal opportunities and no censorship requirements in section 315 also apply to cable system operators, SDARS licensees, and DBS service providers engaged in origination programming. Section 312(a)(7) requires broadcast licensees to give legally qualified candidates for Federal office the opportunity to purchase “reasonable amounts of time.” The reasonable access provisions of section 312(a)(7) also apply to SDARS licensees and DBS service providers engaged in origination programming, but are not applicable to cable system operators.
                </P>
                <P>
                    4. 
                    <E T="03">Political Recordkeeping Requirements.</E>
                     The political recordkeeping requirements serve to reinforce the statutory protections for political programming. The Commission first adopted rules requiring broadcast stations to maintain public inspection files documenting requests for political advertising time more than 80 years ago, and political file obligations have been embodied in section 315(e) of the Act since 2002. Section 315(e)(1) requires broadcast licensees to maintain and make available for public inspection information about each request for the purchase of broadcast time that is made: (a) by or on behalf of a legally qualified candidate for public office, or (b) by an issue advertiser whose advertisement communicates a message relating to a political matter of national importance. It is crucial that stations maintain political files that are complete and up to date because the information in them directly affects, among other things, the statutory rights of opposing candidates to request equal opportunities under section 315(a) of the Act and present 
                    <PRTPAGE P="63383"/>
                    their positions to the public prior to an election. In addition, as the Commission has stated, “the disclosures included in the political file further the First Amendment's goal of an informed electorate that is able to evaluate the validity of messages and hold accountable the interests that disseminate political advocacy.” Section 315(e)(2) specifies the kinds of records that must be maintained in political files, and section 315(e)(3) provides that these records must be placed in the political file “as soon as possible” and retained for a period of at least two years. The Commission has also applied political file rules to cable television system operators, DBS providers, and SDARS licensees engaged in origination programming.
                </P>
                <P>
                    5. 
                    <E T="03">Sponsorship Identification Recordkeeping Requirements.</E>
                     Pursuant to section 317 of the Act and § 73.1212 of the Commission's rules, broadcast stations are required to make on-air sponsorship identification announcements when any valuable consideration is paid or promised to them in exchange for the broadcast of program material. Section 73.1212(e) also requires broadcast stations to comply with certain recordkeeping requirements when the material broadcast is “political matter or matter involving the discussion of a controversial issue of public importance.” The objective of the list retention requirement is to “preserv[e] the audience's right to know by whom it is being persuaded.” The Commission has extended to cable operators that engage in origination cablecasting sponsorship identification and recordkeeping requirements that are largely the same as those applicable to broadcasters.
                </P>
                <HD SOURCE="HD1">Other Federal and State Actions</HD>
                <P>6. The Federal Election Commission (FEC) currently is considering a petition for rulemaking filed by Public Citizen requesting that the FEC amend its rules to clarify that existing campaign law prohibiting fraudulent misrepresentation by candidates for Federal office and their agents applies to deliberately deceptive AI-generated content in campaign ads or other campaign communications. To date, eleven States—California, Idaho, Indiana, Michigan, Minnesota, New Mexico, Oregon, Texas, Utah, Washington, and Wisconsin—have enacted legislation regulating AI-generated “deepfakes” in political ads and other campaign communications. In addition, similar legislation is awaiting governor signature or under consideration in 28 states.</P>
                <P>7. Notably, there are distinctions between these Federal and state actions and our proposals in the instant proceeding. For example, the FEC petition for rulemaking would clarify that a prohibition on fraudulent misrepresentation in campaign ads by or on behalf of candidates for Federal office applies to deceptive AI-generated content in such ads, while our proposal would require on-air disclosures in ads by or on behalf of candidates for both Federal and state offices and issue ads that contain any AI-generated content. Our proposals are meant to complement, not replace, this effort, which has the common goal of ensuring an informed public. The final and proposed state actions vary widely, and some explicitly exempt ads aired by broadcast stations. Our proposed on-air disclosure requirement would ensure that broadcast stations and other affected Commission licensees and regulatees face uniform requirements.</P>
                <HD SOURCE="HD1">Potential Public Interest Benefits and Harms of Using AI-Generated Content in Political Ads</HD>
                <P>8. With recent advancements and rapid growth in generative AI tools, the use of AI is expected to play a substantial role in the creation of political ads in 2024 and beyond. The Commission anticipates that the use of AI technologies in political ads could provide a number of benefits. The use of AI-generated content could help candidates and issue advertisers tailor their messages to specific communities. For example, a campaign could use AI tools to generate messages targeted to the unique concerns of certain demographics or to produce content in the candidate's voice in multiple languages. AI could also help to speed up and automate the generation of political ads, enabling campaigns and issue advertisers to create new content quickly in the final days leading up to an election. Additionally, because new AI tools are inexpensive, require little training to use, and are capable of generating a large volume of content, such tools could be valuable to smaller campaigns with limited financial resources, allowing them to reach more voters and compete more effectively with larger, well-funded campaigns. The Commission seeks comment on other benefits that the use of AI technologies in political ads could provide.</P>
                <P>9. The use of AI-generated content in political ads, however, also creates a potential for providing deceptive, misleading, or fraudulent information to voters. Of particular concern is the use of AI-generated “deepfakes”—altered images, videos, or audio recordings that depict people doing or saying things they did not actually do or say, or events that did not actually occur. Such manipulated media could mislead the public about candidates' assertions or positions on particular issues or about whether certain events actually happened, creating confusion and distrust among potential voters. Moreover, AI tools could be used to produce convincingly false messages about where or when to cast a ballot, or to discourage voters from showing up to their polling locations. To be sure, deceptive political advertising is nothing new. Even before the emergence of AI technologies, tools such as Photoshop have been used to manipulate images used in political ads. The advancement and widespread availability of AI tools, however, has made it easier, faster, and less expensive to make sophisticated and realistic “deepfakes” and other manipulated media, making it increasingly more difficult for voters to discern what is real and what is fake. The Commission seeks comment on these and other potentially harmful effects of using AI-generated content in political ads. Do these potentially harmful effects support Commission intervention in order to ensure that the public is informed of the presence of AI-generated content?</P>
                <HD SOURCE="HD1">Proposed Definition of “AI-Generated Content”</HD>
                <P>
                    10. The Commission seeks comment on how to define “AI-generated content” for purposes of this proceeding. In general, AI can encompass a wide range of technologies and functions, and AI technologies include programs that emulate aspects of human intelligence, such as a human voice. While the Commission has not yet adopted a specific definition of “artificial intelligence,” various organizations and statutes have defined AI. In October 2023, President Biden's 
                    <E T="03">Executive Order on the Safe, Secure, and Trustworthy Development and Use of Artificial Intelligence</E>
                     (E.O. 14110, 88 FR 75191 (November 1, 2023)) drew upon a statutory definition of AI established by the National Artificial Intelligence Initiative in 2021 and set forth in 15 U.S.C. 9401(3), which defines AI as “a machine-based system that can, for a given set of human-defined objectives, make predictions, recommendations, or decisions influencing real or virtual environments.” The Defense Authorization Act of 2019 provided similar definitions of artificial intelligence, including “an artificial system designed to act rationally, including a software agent or embodied 
                    <PRTPAGE P="63384"/>
                    robot that achieves goals using perception, planning, reasoning, learning, communication, decision making, and acting.”
                </P>
                <P>11. The Commission proposes to define “AI-generated content” for purposes of this proceeding as “an image, audio, or video that has been generated using computational technology or other machine-based system that depicts an individual's appearance, speech, or conduct, or an event, circumstance, or situation, including, in particular, AI-generated voices that sound like human voices, and AI-generated actors that appear to be human actors.” The Commission believes this definition would adequately encompass content artificially created for use in political advertising. The Commission seeks comment on this proposed definition and invites commenters to propose alternative definitions.</P>
                <HD SOURCE="HD1">Proposal To Require Broadcasters To Disclose Use of AI-Generated Content in Political Ads</HD>
                <P>12. The Commission proposes to require that all radio and television broadcast stations that air political ads inquire whether political ads scheduled to be aired on their stations contain AI-generated content and provide an on-air announcement for all such ads disclosing the use of AI-generated content in the ad. It further proposes to require all broadcast stations that air political ads to include in their online political files a notice disclosing the use of AI-generated content for each political ad that contains such content. As discussed above, broadcasters have an obligation under the Communications Act to operate in the public interest. Given the potential for AI-generated content in political ads to provide false, misleading, and/or deceptive information to the public, the Commission seeks comment on whether requiring broadcasters to disclose the use of AI-generated content in political ads is consistent with their statutory obligation to serve the public interest by ensuring that listeners and viewers have the necessary information to evaluate such ads for themselves.</P>
                <P>13. Notably, the Commission is not proposing to ban or restrict the use of AI-generated content in producing political ads. Instead, it is merely proposing that listeners and viewers be informed when a political ad contains such content. The use of AI could help political advertisers provide timely, accurate, and relevant information to potential voters, or AI tools could be used to provide potential voters misleading or deceptive information. The Commission believes that disclosing that a political ad contains AI-generated content could help the listening or viewing audience make informed decisions about the information in that ad. The Commission seeks comment on this view.</P>
                <P>
                    14. 
                    <E T="03">Proposal to Require Broadcasters to Inquire Whether Political Ads Contain AI-Generated Content.</E>
                     The Commission proposes to require that all broadcast stations that air political ads inquire whether political ads scheduled to be aired on their stations contain any AI-generated content, as defined in this proceeding. Under this proposal, a broadcast station would fulfill its obligation by making a simple inquiry to the person or entity making the request for the purchase of airtime as to whether a political ad includes AI-generated content, as defined herein. Specifically, a broadcast station would be required to inform the person or entity requesting airtime, at the time an agreement is reached to air a political ad, that the station is required to make an on-air disclosure for any political ad that includes such AI-generated content and inquire whether the ad does in fact include such AI-generated content. Comment is sought on this proposal. Would such an inquiry be expected to identify all political ads that use AI-generated content (that is, would the person or entity making the request for airtime generally be expected to know whether the ad was created using AI-generated content)? Are there any additional or alternative actions that we should require broadcast stations to take to inquire whether a political ad uses AI-generated content? Comment is also sought on how stations should go about making the inquiry. For example, should we require that the station's inquiry to the person or entity making the request for the purchase of airtime be made in writing so that there is a record of the request? What if the person or entity requesting airtime fails to respond to a station's inquiry? Should a station that makes a simple inquiry consistent with the Commission's rules be deemed to have satisfied its obligations even if there is no response to the inquiry? Additionally, there may be instances where a station is informed by a third party that a political ad contains AI-generated content where there was no previous affirmative response to the station's inquiry. In these cases, should a station be required to re-inquire with the person or entity making the request for the purchase of airtime?
                </P>
                <P>
                    15. 
                    <E T="03">Proposal to Require Broadcasters to Make On-Air Announcement Disclosing the Use of AI-Generated Content in Political Ads.</E>
                     In cases where a political ad scheduled to be aired on a broadcast station contains AI-generated content, the Commission proposes to require the station to make an on-air announcement disclosing that the ad contains AI-generated content. The station would be required to make the on-air announcement immediately preceding or during the broadcast of any ad by or on behalf of a legally qualified candidate for public office and any issue ad that contains AI-generated content. The Commission seeks comment on this proposal. The Commission seeks comment on whether a disclosure immediately preceding or during the ad would be more prominent and bring greater awareness of the fact that the ad contains AI-generated content than a disclosure immediately following the ad. Alternatively, The Commission seeks comment on whether broadcasters should be permitted to air the disclosure at any time immediately preceding, during, or immediately following the ad.
                </P>
                <P>
                    16. The Commission further proposes that broadcasters use standardized language for the on-air disclosure. For radio ads, it proposes that broadcasters provide an on-air announcement orally in a voice that is clear, conspicuous, and a speed that is understandable, stating that: “The following message contains information generated in whole or in part by artificial intelligence.” For television ads, it proposes that broadcasters provide an on-air announcement immediately preceding or during the ad either (i) orally in a voice that is clear, conspicuous, and at a speed that is understandable, stating that: “The following message contains information generated in whole or in part by artificial intelligence” or “This message contains information generated in whole or in part by artificial intelligence,”; or (ii) visually with letters equal to or greater than four percent of the vertical picture height for at least four seconds, stating that: “The following message contains information generated in whole or in part by artificial intelligence” or “This message contains information generated in whole or in part by artificial intelligence.” To the extent that we conclude that broadcasters should have the option to air the disclosure immediately following the ad, this language could be modified as appropriate to state: “The preceding message contains information generated in whole or in part by artificial intelligence.” The Commission seeks comment on the proposal to require standardized language and on the specific language that we have proposed. Is the proposed language 
                    <PRTPAGE P="63385"/>
                    sufficient to inform listeners and viewers that an ad's content may require further evaluation to determine whether it contains misleading or inaccurate information? Should the disclosure be in English, in the primary language of the broadcast if other than English, or both? Should television broadcasters have the option to make the on-air disclosure either orally or visually, or should they be required to make the disclosure both orally and visually to ensure that it is accessible to individuals with visual or hearing impairments? In instances where a simple inquiry to the candidate or other entity requesting airtime reveals that there is no AI-generated content in a political ad, the broadcaster would not be required to make any on-air disclosure. However, the Commission seeks comment on the appropriate actions for stations to take in cases where a station is informed by a credible third party that a political ad contains AI-generated content where there was no previous affirmative response to the station's inquiry or the station received a negative response to its inquiry. In these circumstances, should a station be required to follow up with the purchaser of the ad and/or insert the required disclosure? The Commission notes that candidate ads are already required to include an on-air disclosure that the candidate has approved the ad. It seeks comment on where the proposed on-air disclosure regarding AI-generated content would be placed in the audio or video feed relative to the existing disclosure.
                </P>
                <P>
                    17. 
                    <E T="03">Proposal to Require Broadcasters to Include in Their Political Files a Notice Disclosing Use of AI-Generated Content in Political Ads.</E>
                     The Commission also proposes to require all broadcast stations to include in their online political files a notice disclosing the use of AI-generated content for each political ad that contains such content. Under this proposal, broadcasters would include a notice for each political ad that contains AI-generated content using the same standardized language discussed above: “This message contains information generated in whole or in part by artificial intelligence.” The Commission seeks comment on this proposal. The Commission believes that this requirement would help to foster greater transparency regarding the use of AI-generated content in political ads by, for example, allowing listeners, viewers, and other interested parties to confirm which ads aired by a station contained AI-generated content. Nevertheless, it seeks comment on whether it would be sufficient for the broadcaster to provide only an on-air disclosure.
                </P>
                <P>
                    18. The Commission also seeks comment on whether notices of AI-generated content included in broadcasters' political file would be “data assets” potentially subject to the requirements of the OPEN Government Data Act. The OPEN Government Data Act requires agencies to make “public data assets” available under an open license and as “open Government data assets,” 
                    <E T="03">i.e.,</E>
                     in machine-readable, open format, unencumbered by use restrictions other than intellectual property rights, and based on an open standard that is maintained by a standards organization. This requirement is to be implemented “in accordance with guidance by the Director” of the OMB.
                </P>
                <P>19. The Commission tentatively concludes that notices of AI-generated content included in broadcasters' political files would not constitute “data assets” as defined in 44 U.S.C. 3502(17). A “data asset” is defined as “a collection of data elements or data sets that may be grouped together,” and “data” as “recorded information, regardless of form or the media on which the data is recorded.” Each AI-generated content notice, however, is separate and distinct from one another and the information contained in the political files generally is unstructured rather than systematically arranged in a table or database, such that the information could not readily be grouped together in any meaningful way. The Commission tentatively concludes therefore that, in the absence of a standardized collection form, the proposed AI-generated content notices would not constitute a “data asset” subject to the requirements of the OPEN Government Data Act. The Commission seeks comment on this tentative conclusion.</P>
                <P>
                    20. 
                    <E T="03">Applicability of Proposed Disclosure Requirements to Political Ads Embedded in Network or Syndicated Programming.</E>
                     The Commission seeks comment on whether and how the proposed on-air and political file disclosure requirements should be applied to a candidate or issue ad that is embedded within a network or syndicated program aired by a broadcast station. The Commission notes that in instances where a political ad is embedded in network or syndicated programming, a broadcast station airing the programming would not have direct contact with the person or entity requesting to purchase airtime from the network or syndication company for the political ad. In such cases, how does a broadcast station airing the network or syndicated programming currently comply with its obligations under the political programming and political file rules? Does the network or syndication company generally inform the broadcast stations airing the programming, at some point prior to the scheduled broadcast date, that a particular program includes a political ad? Should the Commission require broadcast stations to make a simple inquiry to the respective network or syndication company, at the time the network or syndication company informs the stations airing the programming that a political ad is embedded in a particular program, whether the ad contains AI-generated content? Alternatively, should the Commission allow broadcast stations to make a simple inquiry of their network and syndication partners at specified intervals (
                    <E T="03">e.g.,</E>
                     annually or at the start of each television season) requesting that the network or syndication company inform the stations each time that a political ad embedded within a program contains AI-generated content, prior to the airing of that program? Would the network or syndication company be expected to know if a political ad embedded within its programming contains AI-generated content? If a simple inquiry to the network or syndication company is unlikely to reveal whether political ads embedded in network and syndicated programming contain AI-generated content, should we exempt broadcast stations from complying with the proposed on-air and political file disclosure requirements with respect to political ads embedded in network or syndicated programming? In cases where a station is informed by a credible third party that a political ad contains AI-generated content where there was no previous affirmative response to the station's inquiry, should a station be required to insert the required disclosure? To the extent that a simple inquiry to a network or syndication company can be expected to reveal whether political ads embedded in network or syndicated programming contain AI-generated content, would it be technically feasible or practical for the stations to insert an on-air announcement disclosing that such ads contain AI-generated content in the network or syndicated programming? If not, should stations be exempted from complying with the proposed on-air disclosure requirement but nevertheless required to comply with the proposed political file disclosure requirement?
                    <PRTPAGE P="63386"/>
                </P>
                <HD SOURCE="HD1">Extension of Proposals to Cable Operators, DBS Providers, and SDARS Licensees That Engage in Origination Programming</HD>
                <P>21. The Commission proposes to extend the proposals for broadcast stations discussed herein to cable operators, DBS providers, and SDARS licensees engaged in origination programming. As discussed above, “origination cablecasting” is “[p]rogramming (exclusive of broadcast signals) carried on a cable television system over one or more channels and subject to the exclusive control of the cable operator.” Similarly, “DBS origination programming” is “programming (exclusive of broadcast signals) carried on a DBS facility over one or more channels and subject to the exclusive control of the DBS provider.” The Commission's rules do not include a definition of “SDARS origination programming.” The Commission proposes to amend the rules by adding a definition of to define “SDARS origination programming” as “programming carried on a SDARS facility over one or more channels and subject to the exclusive control of the SDARS licensee.” The Commission seeks comment on this proposal. Cable operators, DBS providers, and SDARS licensees engaged in origination programming are subject to certain public interest obligations, including political programming and political file requirements. The Commission tentatively conclude that the same public interest justifications that support the proposed rules for broadcast stations apply equally to cable operators, DBS providers, and SDARS licensees engaged in origination programming. The Commission seeks comment on this tentative conclusion.</P>
                <P>22. Consistent with our broadcast station proposals, cable operators, DBS providers, and SDARS licensees, when engaged in origination programming, would be required to inquire whether political ads scheduled to be aired on their systems or facilities contain any AI-generated content and provide an on-air announcement for all such ads disclosing the use of AI-generated content in the ad. The Commission also proposes to use the same standardized language for disclosure of AI-generated content in political ads as proposed for broadcast stations. Further, it proposes to require these entities to include in their political files a notice disclosing the use of AI-generated content in political ads they air. The Commission seeks comment on application of these proposals to cable operators, DBS providers, and SDARS licensees engaged in origination programming.</P>
                <HD SOURCE="HD1">Extension of Proposals to Section 325(c) Permit Holders</HD>
                <P>23. The Commission proposes to extend the on-air disclosure proposed in this proceeding to political ads broadcast pursuant to a section 325(c) permit. A section 325(c) permit is required when an entity produces programming in the United States but, rather than broadcasting the programming from a U.S.-licensed station, transmits or delivers the programming from a U.S. studio to a non-U.S. licensed station in a foreign country and broadcasts the programming from the foreign station with a sufficient transmission power or a geographic location that enables the material to be received consistently in the United States. Section 325(c) permit applications are subject to the requirements of section 309 (applicable to applications for U.S. station licenses). Specifically, the Commission applies “the same criteria for meeting the programming standards component of the public interest, convenience, and necessity requirement to both a domestic license proceeding under section 309 and a cross-border broadcast license proceeding under section 325.”</P>
                <P>24. Consistent with its proposals for U.S.-licensed broadcast stations, the Commission proposes to require section 325(c) permit holders to inquire whether political ads scheduled to be delivered from their U.S. studio to a non-U.S. broadcast station contain any AI-generated content and provide an on-air notice for all such ads disclosing the use of AI-generated content in the ad. The Commission proposes to use the same standardized language for on-air notices as proposed for U.S.-licensed broadcast stations. Comment is sought on these proposals. In addition, comment is sought on whether any of the proposals should be modified for section 325(c) permit holders.</P>
                <P>25. The Commission tentatively concludes that applying the same on-air disclosure requirements proposed in this proceeding for U.S.-licensed stations to section 325(c) permit holders would serve the public interest because, like programming from a U.S.-licensed station, programming transmitted or delivered by a section 325(c) permit holder is received by audiences in the United States. Thus, the obligation to serve the public interest by taking responsibility for material—including false, misleading or deceptive material—disseminated to the public through their facilities applies equally to section 325(c) permit holders. The Commission seeks comment on this tentative conclusion.</P>
                <HD SOURCE="HD1">Statutory Authority</HD>
                <P>
                    26. We seek comment on whether the Commission has the authority to adopt the proposed on-air disclosure and political file requirements for AI-generated content in political ads. Section 303(r) authorizes the Commission, as “public convenience, interest, or necessity requires, . . . to make such regulation and prescribe such restrictions, not inconsistent with law, as may be necessary to carry out the provisions of this Act. . . .” The Commission has relied on its authority under section 303(r) to develop rules necessary to the public interest. For example, the Commission relied on section 303(r), among other general provisions of the Act, to adopt contest rules, explaining that the presentation of false and misleading program material, including advertising, violates a licensee's basic duty to deal honestly with its audience and is contrary to the public interest. The confines of a title III licensee's duty are set by the general standard “the public interest, convenience or necessity,” and thus the Commission also has authority under various sections of the Act, including sections 307(a), 309(a), 309(k)(1)(a), and 335 (for DBS providers) to enact rules in the public interest. We seek comment on whether these provisions authorize us to require broadcasters, SDARS licensees and DBS providers engaged in origination programming, and section 325(c) permit holders to make the proposed on-air and political file disclosures regarding AI-generated content in political ads. In this regard, broadcasters, and SDARS licensees and DBS providers engaged in origination programming, are subject to statutory provisions and the Commission's rules governing political programming and recordkeeping, the fundamental purpose of which is to foster an informed electorate. Are the proposed on-air disclosure and political file requirements necessary to ensure broadcasters and other regulated entities take reasonable measures to address false, misleading, or deceptive material and to ensure that voters have the information needed to assess the reliability and credibility of political ads in order to make informed decisions and therefore would serve the public interest? Are there other statutory provisions, such as sections 303(b), 315, 317, or others, that would support adoption of the proposed on-air disclosure and political file requirements for broadcasters, SDARS 
                    <PRTPAGE P="63387"/>
                    licensees, and DBS providers engaged in origination programming?
                </P>
                <P>27. We note that cable operators engaged in origination programming are not subject to the Commission's rulemaking authority under section 303(r). We seek comment on whether there are other statutory provisions, such as sections 315 or others, that would support adoption of the proposed on-air disclosure and political file requirements for cable operators engaged in origination programming. Section 315 of the Act imposes on broadcast licensees and cable operators certain programming obligations with respect to candidate ads and recordkeeping obligations with respect to both candidate and certain issue ads, and these obligations have been extended to DBS providers and SDARS licensees. Section 315(d) of the Act authorizes the Commission to “prescribe appropriate rules and regulations to carry out the provisions of this section” and section 315(e) imposes certain political record keeping requirements. We seek comment on whether the proposed on-air disclosure and political file requirements are within the Commission's authority under sections 315(d) and/or 315(e). Given that section 315 imposes specific programming obligations only with respect to candidate ads, and not issue ads, does that suggest that this section provides authority to adopt the proposed on-air disclosure requirements only for candidate ads? Alternatively, would the same rationale for adopting the proposed on-air disclosure requirements for candidate ads also justify adopting the proposed disclosure requirements for issue ads?</P>
                <HD SOURCE="HD1">First Amendment Issues</HD>
                <P>28. The Commission seeks comment on whether the proposed rules raise First Amendment concerns, including those pertaining to broadcasters and cable operators, DBS providers, and SDARS licensees that engage in origination cablecasting. To the extent that our proposed rules implicate regulated entities' First Amendment right to free speech, there are various levels of constitutional scrutiny that might apply. For example, content neutral restrictions on broadcasters are subject to review under “heightened rational basis,” and will be upheld if reasonably tailored to satisfy a substantial government interest. If the proposed rules are not considered content-neutral restrictions, then, with respect to broadcasters, the disclosure requirements will be reviewed under intermediate scrutiny, the less rigorous standard applied to content-based restrictions on that medium. Under the intermediate scrutiny test, restrictions are upheld when the government advances “important governmental interests unrelated to the suppression of free speech” and does not “burden substantially more speech than necessary to further those interests.” If strict scrutiny applies, the disclosure requirements will be upheld if the government's interest is “compelling,” and the rules are both “narrowly tailored” to further that interest and the “least restrictive means” of accomplishing the desired objective. The Commission tentatively concludes that the proposed on-air disclosure and political file requirements comport with the First Amendment right to free speech, regardless which level of scrutiny applies. The Commission seeks comment on this tentative conclusion.</P>
                <P>
                    29. 
                    <E T="03">Government interest.</E>
                     The Commission tentatively concludes that it has a compelling interest in providing greater transparency regarding the use of AI-generated content in political advertising. The Commission has long recognized that broadcasters must assume responsibility for all material which is broadcast through their facilities and must take reasonable measure to address any false, misleading, or deceptive matter. In addition, at the very heart of the political programming and recordkeeping requirements enacted by Congress and implemented by the Commission is a recognition of the critical role that political programming plays in fostering an informed electorate. The need for transparency about the use of AI-generated content is particularly pronounced when political ads intended to influence voters are involved. Recent advancements in generative AI technologies have led to their widespread use, and AI is expected to play a growing role in the future production of political ads. While the use of AI technologies to create political ads may provide benefits, it can also result in the dissemination of deceptive, misleading, or fraudulent information to voters.
                </P>
                <P>30. The proposed on-air disclosure and political file requirements would further the government interest in ensuring that broadcasters and other program distributors fulfill their responsibilities regarding the material which they relay through their facilities and take reasonable measures to address potentially false, misleading, or deceptive material and ensuring that the public has the information they need to make informed decisions about the political ads that are carried. Disclosing the use of AI-generated content in political ads is vital to ensuring that the public can assess the substance and credibility of the information they receive. Rather than abridging the free speech rights of broadcasters and cable operators, DBS providers, and SDARS licensees that engage in origination programming, the proposed on-air disclosure and political file rules would further the goals of the First Amendment and Communication Act by ensuring broadcasters and other regulated entities take reasonable measures to address potentially false, misleading, or deceptive political advertising and enhancing the public's ability to evaluate political ads, thus promoting an informed electorate and improving the quality of public discourse. The Commission tentatively concludes that this interest is sufficient to satisfy any standard of First Amendment review that may apply and seeks comment on this analysis.</P>
                <P>
                    31. 
                    <E T="03">Tailoring.</E>
                     The Commission tentatively concludes that the proposed rules are appropriately tailored to serve the government interest. The proposed rules would require the disclosure of any political ad that uses artificial intelligence, defined as “an image, audio, or video generated using computational technology or other machine-based system that depicts an individual's appearance, speech, or conduct, or an event, circumstance, or situation, including, in particular, AI-generated voices that sound like human voices, and AI-generated actors that appear to be human actors.” Since broadcasters and other affected Commission licensees and regulatees would be required to make on-air and political file disclosures only in instances where the ad contains content meeting this definition, and would be allowed to rely on the information provided to them by the person or entity making the request for the purchase of airtime, any administrative burden would be modest. Accordingly, the Commission tentatively concludes that the proposed rules are appropriately tailored to meet any standard that might apply. The Commission seeks comment on this analysis.
                </P>
                <P>
                    32. 
                    <E T="03">The Means Chosen to Accomplish the Government's Objective.</E>
                     The Commission also tentatively concludes that the means chosen to accomplish the government's objective would meet any standard of First Amendment review that might apply. Our proposed on-air disclosure and political file requirements would not prevent or inhibit the airing of political ads, 
                    <E T="03">i.e.,</E>
                     these requirements would not prevent anyone from speaking. Rather, these requirements would promote the goals 
                    <PRTPAGE P="63388"/>
                    of the First Amendment and the Communications Act by ensuring broadcasters and other regulated entities take reasonable measures to address potentially false, misleading, or deceptive material and enhancing the public's ability to assess the substance and reliability of political ads, thus fostering an informed electorate and improving the quality of public discourse. As the Court has previously concluded, “disclosure is a less restrictive alternative to more comprehensive regulations of speech.” Broadcasters and cable operators, DBS providers, and SDARS licensees engaged in origination programming would have the modest burdens of inquiring of the ad sponsor whether the political ad scheduled to be aired contains an AI-generated content and, if it does, making on-air and political file disclosures. For this reason, the Commission anticipates the proposed rules would have little if any impact on the decision to accept political ads containing AI-generated content as compared to other ads. The Commission seeks comment on this analysis.
                </P>
                <P>33. In addition, the Commission tentatively concludes that the analysis provided here applies equally to those operating pursuant to section 325(c) permits, because there is nothing to differentiate them from other broadcast licensees when it comes to political programming requirements, and the governmental interest and effects on speech are the same as to content transmitted by U.S.-licensed broadcasters and content transmitted by section 325(c) permittees over the facilities of a non-U.S. broadcaster.</P>
                <P>34. The Commission also tentatively concludes that the proposed on-air and political file disclosures would not violate the First Amendment rights of the candidates or other entities that sponsor political ads. These proposed rules would further the government's compelling interest in providing greater transparency regarding the use of AI-generated content in political advertising, ensuring that voters have the information they need to make informed decisions about the political ads that are carried on broadcast stations and other affected facilities. Additionally, the Commission tentatively concludes that the proposed rules are appropriately tailored to serve this interest. When purchasing airtime, broadcasters or other regulated entities would simply ask candidates and other entities that sponsor ads whether their ad was created using AI-generated content. If the answer is yes, then the broadcaster or regulated entity would add the necessary disclosure. The proposed definition of AI-generated content is straightforward and simple to apply. Thus, the administrative burden would be modest. Finally, the Commission tentatively concludes that the means chosen to achieve the government's objective would satisfy First Amendment review. The proposed rules would not suppress speech by preventing or inhibiting candidates and other entities that sponsor political ads from using artificial intelligence to produce their ads. Rather, the proposed disclosure requirements would promote the goals of the First Amendment by enhancing the public's ability to evaluate the substance and reliability of political ads, thus fostering an informed electorate and improving the quality of public discourse. As noted above, the Court has previously concluded that “disclosure is a less restrictive alternative to more comprehensive regulations of speech.” The Commission seeks comment on this analysis.</P>
                <HD SOURCE="HD1">Cost-Benefit Analysis</HD>
                <P>
                    35. The Commission seeks comment on the costs and benefits of our proposed rules on broadcasters, cable operators, DBS providers, and SDARS licensees that engage in origination programming, and section 325(c) permit holders, particularly those that are small entities. The Commission tentatively concludes that requiring these entities to make a simple inquiry to the candidate or other entity that requests airtime as to whether a political ad contains AI-generated content would not impose a significant burden on these entities. In this regard, it expects that the candidate or other entity that requests airtime generally would be aware whether or not a particular ad contains AI-generated content. The Commission also tentatively concludes the proposed rules would benefit the public by providing greater transparency regarding the use of AI-generated content in political ads, while imposing a modest burden on the affected entities (
                    <E T="03">i.e.,</E>
                     the burden of making a simple inquiry as to the use of AI-generated content and making an on-air disclosure and/or including a notice in the political file). The Commission seeks comment on these tentative conclusions and on other potential benefits and costs of the proposed rules. The benefits and costs of our rules for disclosing AI-generated content depend on the share of political advertisements for which such disclosure would plausibly be required. The Commission thus seeks estimates of the share of political advertisement for which disclosure of AI-generated would be required. The Commission also seeks comment on the cost to the affected entities of airtime for on-air disclosures aired prior to a political ad (
                    <E T="03">i.e.,</E>
                     airtime that could otherwise be sold to other advertisers). Given that candidate ads are already required to include an on-air disclosure that the candidate has approved the ad, the Commission seeks comment on any burden associated with requiring two on-air disclosures in a single candidate ad. In addition, it requests comment on whether there are any alternative actions that should be taken to minimize any burdens on affected entities, particularly on small entities. For example, should the proposed on-air disclosure and political file requirements be limited to political ads aired in the 60-day period leading up to a primary election and the 90-day period leading up to a general election? Would it significantly reduce burdens on small entities to require only an on-air disclosure informing the public of the use of AI-generated content, and not a separate notice in the online political file?
                </P>
                <HD SOURCE="HD1">Digital Equity and Inclusion</HD>
                <P>36. The Commission, as part of its continuing effort to advance digital equity for all, including people of color, persons with disabilities, persons who live in rural or Tribal areas, and others who are or have been historically underserved, marginalized, or adversely affected by persistent poverty or inequality, invites comment on any equity-related considerations and benefits (if any) that may be associated with the issues discussed herein. Specifically, the Commission seeks comment on how any Commission actions taken to address the use of AI in political advertising may promote or inhibit advances in diversity, equity, inclusion, and accessibility.</P>
                <HD SOURCE="HD1">Initial Regulatory Flexibility Act Analysis</HD>
                <P>
                    37. As required by the Regulatory Flexibility Act of 1980, as amended (RFA), the Commission has prepared this Initial Regulatory Flexibility Act Analysis (IRFA) of the possible significant economic impact on a substantial number of small entities by the policies and rules proposed in the NPRM. Written public comments are requested on this IRFA. Comments must be identified as responses to the IRFA and must be filed by the deadlines for comments provided in the 
                    <E T="02">DATES</E>
                     section of this document. The Commission will send a copy of the NPRM, including the IRFA, to the Chief Counsel for Advocacy of the Small Business Administration (SBA). In addition, the NPRM and IRFA 
                    <PRTPAGE P="63389"/>
                    (or summaries thereof) will be published in the 
                    <E T="04">Federal Register</E>
                    .
                </P>
                <HD SOURCE="HD2">A. Need for, and Objectives of, the Proposed Rules</HD>
                <P>38. The presentation of political programming has long been recognized as an essential element of broadcasters' obligation to serve the public interest because of the critical role such programming plays in fostering an informed electorate, which in turn is vital to the effective operation of the democratic process. The political programming and recordkeeping requirements established by Congress and implemented by the Commission ensure that candidates for elective office have access to broadcast facilities and certain other media platforms and foster transparency about the entities that sponsor political ads.</P>
                <P>39. The use of emerging artificial intelligence (AI) technologies in political ads can serve the public interest in fostering an informed electorate by, for example, allowing candidates to tailor their messages to specific populations or empowering smaller political campaigns with limited financial resources to reach larger audiences. The use of AI technologies in political advertising, however, also has the potential to produce “deepfakes” and other deceptive and misleading information, creating confusion among the voting public. Accordingly, the Commission initiates the NPRM to further the public interest by ensuring broadcasters and other regulated entities take reasonable measures to address potentially false, misleading or deceptive material and promoting an informed electorate.</P>
                <P>40. The NPRM proposes to define “AI-generated content” for purposes of this proceeding as “an image, audio, or video that has been generated using computational technology or other machine-based system that depicts an individual's appearance, speech, or conduct, or an event, circumstance, or situation, including, in particular, AI-generated voices that sound like human voices, and AI-generated actors that appear to be human actors.” The NPRM also proposes to require that all radio and television broadcast stations inquire whether political ads scheduled to be aired on their stations contain any AI-generated content and make an on-air announcement for all such ads disclosing the use of AI-generated content in the ad. Under this proposal, broadcast stations would fulfill their obligation by making a simple inquiry to the person or entity that submits the request for the purchase of airtime as to whether a political ad includes AI-generated content. Further, the NPRM proposes to require that broadcasters make the on-air disclosure at the beginning of or during the ad and use standardized language for the disclosure and to require broadcast stations to include in their online political files a notice, using standardized language, disclosing the use of AI-generated content for each political ad that contains such content. Moreover, the NPRM proposes to extend these proposed on-air disclosure and political file requirements to cable operators, DBS providers, and SDARS licensees engaged in origination programming and to permit holders transmitting programming pursuant to section 325(c) of the Act. The NPRM does not propose to ban or otherwise restrict the use of AI-generated content in political ads. Instead, it merely seeks to ensure that the listening and viewing public is informed when political ads include such content.</P>
                <HD SOURCE="HD2">B. Legal Basis</HD>
                <P>41. The proposed action is authorized pursuant to sections 1, 4(i), 303, 307, 309, 312, 315, 317, 325(c)-(d), and 335 of the Communications Act of 1934, as amended, 47 U.S.C. 151, 154(i), 303, 307, 309, 312, 315, 317, 325(c)-(d), and 335.</P>
                <HD SOURCE="HD2">C. Description and Estimates of the Number of Small Entities to Which the Proposed Rules Will Apply</HD>
                <P>42. The RFA directs agencies to provide a description of and, where feasible, an estimate of the number of small entities that may be affected by the proposed rules, if adopted. The RFA generally defines the term “small entity” as having the same meaning as the terms “small business,” “small organization,” and “small governmental jurisdiction.” In addition, the term “small business” has the same meaning as the term “small business concern” under the Small Business Act. A small business concern is one which: (1) is independently owned and operated; (2) is not dominant in its field of operation; and (3) satisfies any additional criteria established by the SBA.</P>
                <P>
                    43. 
                    <E T="03">Cable Companies and Systems (Rate Regulation).</E>
                     The Commission has developed its own small business size standard for the purpose of cable rate regulation. Under the Commission's rules, a “small cable company” is one serving 400,000 or fewer subscribers nationwide. Based on industry data, there are about 420 cable companies in the U.S. Of these, only seven have more than 400,000 subscribers. In addition, under the Commission's rules, a “small system” is a cable system serving 15,000 or fewer subscribers. Based on industry data, there are about 4,139 cable systems (headends) in the U.S. Of these, about 639 have more than 15,000 subscribers. Accordingly, the Commission estimates that the majority of cable companies and cable systems are small.
                </P>
                <P>
                    44. 
                    <E T="03">Cable System Operators (Telecom Act Standard).</E>
                     The Communications Act of 1934, as amended, contains a size standard for a “small cable operator,” which is “a cable operator that, directly or through an affiliate, serves in the aggregate fewer than one percent of all subscribers in the United States and is not affiliated with any entity or entities whose gross annual revenues in the aggregate exceed $250,000,000.” For purposes of the Telecom Act Standard, the Commission determined that a cable system operator that serves fewer than 498,000 subscribers, either directly or through affiliates, will meet the definition of a small cable operator. Based on industry data, only six cable system operators have more than 498,000 subscribers. Accordingly, the Commission estimates that the majority of cable system operators are small under this size standard. We note however, that the Commission neither requests nor collects information on whether cable system operators are affiliated with entities whose gross annual revenues exceed $250 million. Therefore, we are unable at this time to estimate with greater precision the number of cable system operators that would qualify as small cable operators under the definition in the Communications Act.
                </P>
                <P>
                    46. 
                    <E T="03">Direct Broadcast Satellite (DBS) Service.</E>
                     DBS service is a nationally distributed subscription service that delivers video and audio programming via satellite to a small parabolic “dish” antenna at the subscriber's location. DBS is included in the Wired Telecommunications Carriers industry which comprises establishments primarily engaged in operating and/or providing access to transmission facilities and infrastructure that they own and/or lease for the transmission of voice, data, text, sound, and video using wired telecommunications networks. Transmission facilities may be based on a single technology or combination of technologies. Establishments in this industry use the wired telecommunications network facilities that they operate to provide a variety of services, such as wired telephony services, including Voice over internet Protocol (VoIP) services, wired (cable) audio and video programming distribution; and wired broadband internet services. By exception, establishments providing satellite 
                    <PRTPAGE P="63390"/>
                    television distribution services using facilities and infrastructure that they operate are included in this industry.
                </P>
                <P>47. The SBA small business size standard for Wired Telecommunications Carriers classifies firms having 1,500 or fewer employees as small. U.S. Census Bureau data for 2017 show that 3,054 firms operated in this industry for the entire year. Of this number, 2,964 firms operated with fewer than 250 employees. Based on this data, the majority of firms in this industry can be considered small under the SBA small business size standard. According to Commission data however, only two entities provide DBS service—DIRECTV (owned by AT&amp;T) and DISH Network, which require a great deal of capital for operation. DIRECTV and DISH Network both exceed the SBA size standard for classification as a small business. Therefore, we must conclude based on internally developed Commission data, in general DBS service is provided only by large firms.</P>
                <P>
                    48. 
                    <E T="03">Radio Stations.</E>
                     This industry is comprised of “establishments primarily engaged in broadcasting aural programs by radio to the public.” Programming may originate in their own studio, from an affiliated network, or from external sources. The SBA small business size standard for this industry classifies firms having $41.5 million or less in annual receipts as small. U.S. Census Bureau data for 2017 show that 2,963 firms operated in this industry during that year. Of this number, 1,879 firms operated with revenue of less than $25 million per year. Based on this data and the SBA's small business size standard, we estimate a majority of such entities are small entities.
                </P>
                <P>49. The Commission estimates that as of March 31, 2024, there were 4,427 licensed commercial AM radio stations and 6,663 licensed commercial FM radio stations, for a combined total of 11,090 commercial radio stations. Of this total, 11,088 stations (or 99.98%) had revenues of $41.5 million or less in 2022, according to Commission staff review of the BIA Kelsey Inc. Media Access Pro Database (BIA) on April 4, 2024, and therefore these licensees qualify as small entities under the SBA definition. In addition, the Commission estimates that as of March 31, 2024, there were 4,320 licensed noncommercial (NCE) FM radio stations, 1,960 low power FM (LPFM) stations, and 8,913 FM translators and boosters. The Commission however does not compile, and otherwise does not have access to financial information for these radio stations that would permit it to determine how many of these stations qualify as small entities under the SBA small business size standard. Nevertheless, given the SBA's large annual receipts threshold for this industry and the nature of radio station licensees, we presume that all of these entities qualify as small entities under the above SBA small business size standard.</P>
                <P>50. We note, however, that in assessing whether a business concern qualifies as “small” under the above definition, business (control) affiliations must be included. Our estimate, therefore, likely overstates the number of small entities that might be affected by our action, because the revenue figure on which it is based does not include or aggregate revenues from affiliated companies. In addition, another element of the definition of “small business” requires that an entity not be dominant in its field of operation. We are unable at this time to define or quantify the criteria that would establish whether a specific radio or television broadcast station is dominant in its field of operation. Accordingly, the estimate of small businesses to which the rules may apply does not exclude any radio or television station from the definition of a small business on this basis and is therefore possibly over-inclusive. An additional element of the definition of “small business” is that the entity must be independently owned and operated. Because it is difficult to assess these criteria in the context of media entities, the estimate of small businesses to which the rules may apply does not exclude any radio or television station from the definition of a small business on this basis and similarly may be over-inclusive.</P>
                <P>
                    51. 
                    <E T="03">Television Broadcasting.</E>
                     This industry is comprised of “establishments primarily engaged in broadcasting images together with sound.” These establishments operate television broadcast studios and facilities for the programming and transmission of programs to the public. These establishments also produce or transmit visual programming to affiliated broadcast television stations, which in turn broadcast the programs to the public on a predetermined schedule. Programming may originate in their own studio, from an affiliated network, or from external sources. The SBA small business size standard for this industry classifies businesses having $41.5 million or less in annual receipts as small. 2017 U.S. Census Bureau data indicate that 744 firms in this industry operated for the entire year. Of that number, 657 firms had revenue of less than $25,000,000. Based on this data we estimate that the majority of television broadcasters are small entities under the SBA small business size standard.
                </P>
                <P>52. As of March 31, 2024, there were 1,382 licensed commercial television stations. Of this total, 1,263 stations (or 91.4%) had revenues of $41.5 million or less in 2022, according to Commission staff review of the BIA on April 4, 2024, and therefore these licensees qualify as small entities under the SBA definition. In addition, the Commission estimates as of March 31, 2024, there were 383 licensed noncommercial educational (NCE) television stations, 379 Class A TV stations, 1,829 low power television (LPTV) stations and 3,118 TV translator stations. The Commission, however, does not compile and otherwise does not have access to financial information for these television broadcast stations that would permit it to determine how many of these stations qualify as small entities under the SBA small business size standard. Nevertheless, given the SBA's large annual receipts threshold for this industry and the nature of these television station licensees, we presume that all of these entities qualify as small entities under the above SBA small business size standard.</P>
                <P>
                    53. 
                    <E T="03">Wired Telecommunications Carriers.</E>
                     The U.S. Census Bureau defines this industry as establishments primarily engaged in operating and/or providing access to transmission facilities and infrastructure that they own and/or lease for the transmission of voice, data, text, sound, and video using wired communications networks. Transmission facilities may be based on a single technology or a combination of technologies. Establishments in this industry use the wired telecommunications network facilities that they operate to provide a variety of services, such as wired telephony services, including VoIP services, wired (cable) audio and video programming distribution, and wired broadband internet services. By exception, establishments providing satellite television distribution services using facilities and infrastructure that they operate are included in this industry. Wired Telecommunications Carriers are also referred to as wireline carriers or fixed local service providers.
                </P>
                <P>
                    54. The SBA small business size standard for Wired Telecommunications Carriers classifies firms having 1,500 or fewer employees as small. U.S. Census Bureau data for 2017 show that there were 3,054 firms that operated in this industry for the entire year. Of this number, 2,964 firms operated with fewer than 250 employees. Additionally, based on Commission data in the 2022 Universal Service Monitoring Report, as of December 31, 
                    <PRTPAGE P="63391"/>
                    2021, there were 4,590 providers that reported they were engaged in the provision of fixed local services. Of these providers, the Commission estimates that 4,146 providers have 1,500 or fewer employees. Consequently, using the SBA's small business size standard, most of these providers can be considered small entities.
                </P>
                <HD SOURCE="HD2">D. Description of Projected Reporting, Recordkeeping, and Other Compliance Requirements</HD>
                <P>55. The rule changes proposed in the NPRM, if adopted, would impose compliance and recordkeeping obligations on small, as well as other entities. Specifically, the NPRM proposes to require broadcast stations, cable operators, SDARS licensees, and DBS providers engaged in origination programming, and section 325(c) permit holders, to make a simple inquiry to the candidate or other entity that requests airtime as to whether a political ad contains AI-generated content and provide on air-disclosures informing listeners and viewers that such ads contain AI-generated content. The NPRM further proposes to require that broadcast stations, and cable operators, SDARS licensees, and DBS providers engaged in origination programming, include a notice in their online political files for all political ads that include AI-generated content disclosing that the ad contains such content.</P>
                <P>
                    56. At this time the record does not include sufficient cost/benefit analyses to allow the Commission to quantify the costs of compliance for small entities including whether it will be necessary for small entities to hire professionals to comply with the proposed rules if adopted. The Commission expects, however, that the proposed rules would impose only a modest burden on the affected entities (
                    <E T="03">i.e.,</E>
                     the burden of making a simple inquiry as to the use of AI-generated content and making an on-air disclosure and/or including a notice in the political file), because the candidates or entities requesting airtime should be aware of whether the ad which they seek to have aired contains AI-generated content. The NPRM nevertheless seeks comment, particularly for small entities, on the costs and burdens of the proposed rules and whether there are any actions it should take to minimize any burdens on small entities.
                </P>
                <HD SOURCE="HD2">E. Steps Taken To Minimize Significant Economic Impact on Small Entities, and Significant Alternatives Considered</HD>
                <P>57. The RFA requires an agency to describe any significant, specifically small business, alternatives that it has considered in reaching its proposed approach, which may include the following four alternatives (among others): (1) the establishment of differing compliance or reporting requirements or timetables that take into account the resources available to small entities; (2) the clarification, consolidation, or simplification of compliance and reporting requirements under the rule for such small entities; (3) the use of performance, rather than design, standards; and (4) an exemption from coverage of the rule, or any part thereof, for small entities.</P>
                <P>58. An alternative option that may reduce burdens on small entities considered in the NPRM is whether to limit the proposed on-air disclosure and political file requirements to political ads aired in the 60-day period leading up to a primary election and the 90-day period leading up to a general election. The NPRM also considers whether requiring only an on-air disclosure informing the public of the use of AI-generated content, and not a separate notice in the online political file, would significantly reduce burdens on small entities. To assist in its evaluation of the economic impact of the proposed rules on small entities, and to better explore options and alternatives, the Commission seeks comment on whether any of the burdens associated with the compliance and recordkeeping requirements described above can be minimized for small entities. The Commission expects to more fully consider the economic impact and alternatives for small entities based on its review of the record and any comments filed in response to the NPRM and this IRFA.</P>
                <HD SOURCE="HD2">F. Federal Rules That May Duplicate, Overlap, or Conflict With the Proposed Rule</HD>
                <P>59. None.</P>
                <HD SOURCE="HD1">Ordering Clauses</HD>
                <P>
                    60. 
                    <E T="03">It is ordered</E>
                     that, pursuant to the authority found in sections 1, 4(i), 303, 307, 309, 312, 315, 317, 325(c)-(d), and 335 of the Communications Act of 1934, as amended, 47 U.S.C. 151, 154(i), 303, 307, 309, 312, 315, 317, 325(c)-(d), and 335, the Notice of Proposed Rulemaking 
                    <E T="03">IS ADOPTED.</E>
                </P>
                <P>
                    62. 
                    <E T="03">It is further ordered</E>
                     that, pursuant to applicable procedures set forth in §§ 1.415 and 1.419 of the Commission's rules, 47 CFR 1.415, 1.419, interested parties may file comments on the Notice of Proposed Rulemaking in MB Docket No. 24-211 on or before thirty (30) days after publication in the 
                    <E T="04">Federal Register</E>
                     and reply comments on or before forty-five (45) days after publication in the 
                    <E T="04">Federal Register</E>
                    .
                </P>
                <LSTSUB>
                    <HD SOURCE="HED">List of Subjects in 47 CFR Parts 25, 73, and 76</HD>
                    <P>Radio, Reporting and recordkeeping requirements, Satellites, Television.</P>
                </LSTSUB>
                <SIG>
                    <FP>Federal Communications Commission.</FP>
                    <NAME>Katura Jackson,</NAME>
                    <TITLE>Federal Register Liaison Officer.</TITLE>
                </SIG>
                <P>For the reasons discussed herein, the Federal Communications Commission proposes to amend 47 CFR parts 25, 73, and 76 as follows:</P>
                <PART>
                    <HD SOURCE="HED">PART 25—SATELLITE COMMUNICATIONS</HD>
                </PART>
                <AMDPAR>1. The authority citation for part 25 continues to read as follows:</AMDPAR>
                <AUTH>
                    <HD SOURCE="HED">Authority:</HD>
                    <P> 47 U.S.C. 154, 301, 302, 303, 307, 309, 310, 319, 332, 605, and 721, unless otherwise noted.</P>
                </AUTH>
                <AMDPAR>2. Amend § 25.701 by:</AMDPAR>
                <AMDPAR>a. Adding paragraph (b)(5); and</AMDPAR>
                <AMDPAR>b. Redesignating paragraph (d)(4) as paragraph (d)(5); and</AMDPAR>
                <AMDPAR>c. Adding new paragraph (d)(4).</AMDPAR>
                <P>The additions read as follows:</P>
                <SECTION>
                    <SECTNO>§ 25.701</SECTNO>
                    <SUBJECT>Other DBS Public interest obligations.</SUBJECT>
                    <STARS/>
                    <P>(b) * * *</P>
                    <P>
                        (5) 
                        <E T="03">Disclosure of artificial intelligence-generated content in political advertising.</E>
                         (i) 
                        <E T="03">Artificial intelligence-generated content</E>
                         is defined for purposes of this section as set forth in § 73.1945(a) of this chapter.
                    </P>
                    <P>
                        (ii) 
                        <E T="03">Political advertising</E>
                         is defined for purposes of this section as set forth in § 73.1945(b) of this chapter.
                    </P>
                    <P>(iii) Each DBS provider engaged in origination programming must inquire whether any political advertising scheduled to be aired on its facilities contains any artificial intelligence-generated content. Such inquiry shall be made, in writing to the person or entity making the request for the purchase of political advertising time, at the time that an agreement is reached to air the political advertising on the DBS provider's facilities.</P>
                    <P>
                        (iv) If a DBS provider's inquiry pursuant to paragraph (b)(5)(iii) of this section finds that any political advertising scheduled to be aired on its facilities contains any artificial intelligence-generated content, the DBS provider must make an on-air announcement, immediately preceding or during the airing of the advertising, stating: “[The following] or [This] message contains information generated in whole or in part by artificial intelligence.” The on-air announcement 
                        <PRTPAGE P="63392"/>
                        may be provided either orally in a voice that is clear, conspicuous, and at a speed that is understandable, or visually with letters equal to or greater than four percent of the vertical picture height for at least four seconds.
                    </P>
                    <STARS/>
                    <P>(d) * * *</P>
                    <P>(4) In the case of political advertising, as defined in § 73.1945(b) of this chapter, found by inquiry from a DBS provider engaged in origination program to contain any artificial intelligence-generated content, as defined in § 73.1945(a) of this chapter, the DBS provider shall place in the online political file a notice stating that “This message contains information generated in whole or in part by artificial intelligence.”</P>
                    <STARS/>
                </SECTION>
                <AMDPAR>3. Amend § 25.702 by:</AMDPAR>
                <AMDPAR>a. Revising paragraph (a); and</AMDPAR>
                <AMDPAR>b. Redesignating paragraph (b)(4) as paragraph (b)(5); and</AMDPAR>
                <AMDPAR>c. Adding new paragraph (b)(4).</AMDPAR>
                <P>The revisions and additions read as follows:</P>
                <SECTION>
                    <SECTNO>§ 25.702</SECTNO>
                    <SUBJECT>Other SDARS Public interest obligations.</SUBJECT>
                    <P>
                        (a) 
                        <E T="03">Political broadcasting requirements.</E>
                         The following political broadcasting rules shall apply to all SDARS licensees: 47 CFR 73.1940, 73.1941, 73.1942, 73.1944, and 73.1945. 
                        <E T="03">SDARS origination programming</E>
                         is defined as programming carried on a SDARS facility over one or more channels and subject to the exclusive control of the SDARS licensee.
                    </P>
                    <P>(b) * * * </P>
                    <P>(4) In the case of political advertising, as defined in § 73.1945(b) of this chapter, found by inquiry from a SDARS licensee engaged in origination program to contain any artificial intelligence-generated content, as defined in § 73.1945(a) of this chapter, the SDARS licensee shall place in the online political file a notice stating that “This message contains information generated in whole or in part by artificial intelligence.”</P>
                    <STARS/>
                </SECTION>
                <PART>
                    <HD SOURCE="HED">PART 73—RADIO BROADCAST SERVICES</HD>
                </PART>
                <AMDPAR>4. The authority citation for part 73 continues to read as follows:</AMDPAR>
                <AUTH>
                    <HD SOURCE="HED">Authority:</HD>
                    <P> 47 U.S.C. 154, 155, 301, 303, 307, 309, 310, 334, 336, 339.</P>
                </AUTH>
                <AMDPAR>5. Amend § 73.1943 by redesignating paragraph (d) as paragraph (e) and adding new paragraph (d) to read as follows: </AMDPAR>
                <SECTION>
                    <SECTNO>§ 73.1943</SECTNO>
                    <SUBJECT>Political file.</SUBJECT>
                    <STARS/>
                    <P>(d) In the case of political advertising, as defined in § 73.1945(b), found by the licensee's inquiry to contain any artificial intelligence-generated content, as defined in § 73.1945(a), the licensee shall place in the online political file a notice stating that “This message contains information generated in whole or in part by artificial intelligence.”</P>
                    <STARS/>
                </SECTION>
                <AMDPAR>6. Add § 73.1945 to read as follows:</AMDPAR>
                <SECTION>
                    <SECTNO>§ 73.1945</SECTNO>
                    <SUBJECT>Disclosure of artificial intelligence-generated content in political advertising. </SUBJECT>
                    <P>
                        (a) 
                        <E T="03">Artificial intelligence (AI)-generated content</E>
                         is defined for purposes of this section as an image, audio, or video that has been generated using computational technology or other machine-based system that depicts an individual's appearance, speech, or conduct, or an event, circumstance, or situation, including, in particular, AI-generated voices that sound like human voices, and AI-generated actors that appear to be human actors. 
                    </P>
                    <P>
                        (b) 
                        <E T="03">Political advertising</E>
                         is defined for purposes of this section as:
                    </P>
                    <P>(1) Advertising that is made by or on behalf of a legally qualified candidate for public office; or</P>
                    <P>
                        (2) Issue advertising. 
                        <E T="03">Issue advertising</E>
                         is defined for purposes of this section as paid political programming that communicates a message relating to any political matter or controversial issue of public importance, but does not include advertising that is made by or on behalf of a legally qualified candidate for public office. 
                    </P>
                    <P>(c) Each licensee must inquire whether any political advertising scheduled to be aired on its station contains any artificial intelligence-generated content. Such inquiry shall be made in writing to the person or entity making the request for the purchase of political advertising time, at the time that an agreement is reached to air the political advertising on the station.</P>
                    <P>(d) If a licensee's inquiry pursuant to paragraph (c) of this section finds that any political advertising scheduled to be aired on its station contains any artificial intelligence-generated content, the licensee must make an on-air announcement, immediately preceding or during the airing of the advertising, stating: “[The following] or [This] message contains information generated in whole or in part by artificial intelligence.” For radio stations, the on-air announcement must be provided orally in a voice that is clear, conspicuous, and at a speed that is understandable. For television stations, the on-air announcement may be provided either orally in a voice that is clear, conspicuous, and at a speed that is understandable, or visually with letters equal to or greater than four percent of the vertical picture height for at least four seconds. </P>
                </SECTION>
                <PART>
                    <HD SOURCE="HED">PART 76—MULTICHANNEL VIDEO AND CABLE TELEVISION SERVICE</HD>
                </PART>
                <AMDPAR>7. The authority citation for part 76 continues to read as follows:</AMDPAR>
                <AUTH>
                    <HD SOURCE="HED">Authority:</HD>
                    <P> 47 U.S.C. 151, 152, 153, 154, 301, 302, 302a, 303, 303a, 307, 308, 309, 312, 315, 317, 325, 335, 338, 339, 340, 341, 503, 521, 522, 531, 532, 534, 535, 536, 537, 543, 544, 544a, 545, 548, 549, 552, 554, 556, 558, 560, 561, 562, 571, 572, 573.</P>
                </AUTH>
                <AMDPAR>8. Add § 76.207 to read as follows:</AMDPAR>
                <SECTION>
                    <SECTNO>§ 76.207</SECTNO>
                    <SUBJECT>Disclosure of artificial intelligence-generated content in political advertising.</SUBJECT>
                    <P>
                        (a) 
                        <E T="03">Artificial intelligence (AI)-generated content</E>
                         is defined for purposes of this section as an image, audio, or video that has been generated using computational technology or other machine-based system that depicts an individual's appearance, speech, or conduct, or an event, circumstance, or situation, including, in particular, AI-generated voices that sound like human voices, and AI-generated actors that appear to be human actors. 
                    </P>
                    <P>
                        (b) 
                        <E T="03">Political advertising</E>
                         is defined for purposes of this section as:
                    </P>
                    <P>(1) Advertising that is made by or on behalf of a legally qualified candidate for public office; or</P>
                    <P>
                        (2) Issue advertising. 
                        <E T="03">Issue advertising</E>
                         is defined for purposes of this section as paid political programming that communicates a message relating to any political matter or controversial issue of public importance, but does not include advertising that is made by or on behalf of a legally qualified candidate for public office. 
                    </P>
                    <P>(c) Each cable television system operator must inquire whether any political advertising scheduled to be aired on its system contains any artificial intelligence-generated content. Such inquiry shall be made in writing to the person or entity making the request for the purchase of political advertising time, at the time that an agreement is reached to air the political advertising on the system. </P>
                    <P>
                        (d) If a cable television system operator's inquiry pursuant to paragraph (c) of this section finds that any political advertising scheduled to be aired on its station contains any artificial intelligence-generated content, the operator must make an on-air announcement, immediately preceding 
                        <PRTPAGE P="63393"/>
                        or during the airing of the advertising, stating: “[The following] or [This] message contains information generated in whole or in part by artificial intelligence.” The on-air announcement may be provided either orally in a voice that is clear, conspicuous, and at a speed that is understandable, or visually with letters equal to or greater than four percent of the vertical picture height for at least four seconds.
                    </P>
                </SECTION>
                <AMDPAR>9. Amend § 76.1701 by redesignating paragraphs (d) and (e) as paragraphs (e) and (f) and adding new paragraph (d) to read as follows: </AMDPAR>
                <SECTION>
                    <SECTNO>§ 76.1701</SECTNO>
                    <SUBJECT>Political file.</SUBJECT>
                    <STARS/>
                    <P>(d) In the case of political advertising, as defined in § 73.1945(b) of this chapter, found by inquiry from a cable operator engaged in origination cablecasting to contain any artificial intelligence-generated content, as defined in § 73.1945(a) of this chapter, the cable operator shall place in the online political file a notice stating that “This message contains information generated in whole or in part by artificial intelligence.” </P>
                    <STARS/>
                </SECTION>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-16977 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6712-01-P</BILCOD>
        </PRORULE>
        <PRORULE>
            <PREAMB>
                <AGENCY TYPE="N">DEPARTMENT OF COMMERCE</AGENCY>
                <SUBAGY>National Oceanic and Atmospheric Administration</SUBAGY>
                <CFR>50 CFR Part 223</CFR>
                <DEPDOC>[Docket No.: 240508-0132]</DEPDOC>
                <RIN>RIN 0648-BM49</RIN>
                <SUBJECT>Endangered and Threatened Wildlife and Plants; Protective Regulations for the Oceanic Whitetip Shark (Carcharhinus longimanus), Public Hearings</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>National Marine Fisheries Service (NMFS), National Oceanic and Atmospheric Administration (NOAA), Department of Commerce.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notification of public hearings.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>
                        We, NMFS, will hold two public hearings related to our proposed rule to apply protective regulations to the oceanic whitetip shark (
                        <E T="03">Carcharhinus longimanus</E>
                        ) under the Endangered Species Act (ESA).
                    </P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>
                        Public hearings on the proposed protective regulations for the oceanic whitetip shark will be held on the following dates in the evening hours of the affected jurisdictions (Hawai 'i, Guam, the Commonwealth of the Northern Mariana Islands (CNMI), and American Samoa). Times are given in Chamorro Standard Time (ChST), Samoa Standard Time (SST), and Hawai'i Standard Time (HST). Addresses for the venue of the in-person hearing and instructions for joining the virtual hearing are provided under 
                        <E T="02">ADDRESSES</E>
                         below.
                    </P>
                    <P>• An in-person public hearing is scheduled for Tuesday, August 20, 2024, at the King Kamehameha Kona Beach Resort, Kailua-Kona, Hawai'i. Doors will open at 5:30 p.m. HST, the informational meeting will begin at 6 p.m. HST, and the public hearing will begin at 7 p.m. HST.</P>
                    <P>• One virtual hearing is scheduled for the following time and date:</P>
                    <P>
                        ○ 
                        <E T="03">Samoa Standard Time Zone:</E>
                         the informational meeting will begin on Wednesday, August 21, 2024, at 7 p.m. SST, and the public hearing will begin at 8 p.m. SST.
                    </P>
                    <P>
                        ○ 
                        <E T="03">Hawai  'i Standard Time Zone:</E>
                         the informational meeting will begin on Wednesday, August 21, 2024, at 8 p.m. HST, and the public hearing will begin at 9 p.m. HST.
                    </P>
                    <P>
                        ○ 
                        <E T="03">Chamorro Standard Time Zone:</E>
                         the informational meeting will begin on Thursday, August 22, 2024, at 4 p.m. ChST, and the public hearing will begin at 5 p.m. ChST.
                    </P>
                    <P>Comments on the proposed rule (89 FR 41917, May 14, 2024) must be received by September 15, 2024. Comments received after this date may not be accepted.</P>
                </EFFDATE>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>The address for the venue of the in-person hearing and instructions for joining the virtual hearing are provided below.</P>
                    <P>
                        • 
                        <E T="03">Hawai  'i Public Hearing:</E>
                         King Kamehameha Kona Beach Resort, Kailua-Kona, Hawai'i, 75-5660 Palani Road, Kailua-Kona, Hawai'i 96740.
                    </P>
                    <P>
                        • 
                        <E T="03">Virtual Hearing:</E>
                         This hearing will be conducted as a Webex meeting. You may join the Webex meeting using a web browser, the Webex desktop app (app installation required), a mobile app on a phone (app installation required), or audio-only using just a phone call, as specified below.
                    </P>
                    <P>
                        ○ 
                        <E T="03">Join the webinar via this link: https://noaanmfs-meets.webex.com/noaanmfs-meets/j.php?MTID=m3850e903d036865917d076acd702d934</E>
                        .
                    </P>
                    <P>
                        ○ 
                        <E T="03">Webinar number:</E>
                         2830 072 6586 Webinar password: fTJBNncM788 (38526626 when dialing from a phone or video system).
                    </P>
                    <P>
                        ○ 
                        <E T="03">Join by phone:</E>
                         +1-415-527-5035 Access code: 283 007 26586.
                    </P>
                    <P>You may submit comments verbally or in writing at the public hearings, or in writing by any of the following methods:</P>
                    <P>
                        • 
                        <E T="03">Electronic Submissions:</E>
                         Submit all electronic comments via the Federal e- Rulemaking Portal. Go to 
                        <E T="03">https://www.regulations.gov</E>
                         and enter NOAA- NMFS-2023-0117 in the Search box. Click the “Comment” icon, complete the required fields, and enter or attach your comments.
                    </P>
                    <P>
                        • 
                        <E T="03">Mail:</E>
                         Adrienne Lohe, Office of Protected Resources, NMFS, 1315 East-West Highway, Silver Spring, MD 20910.
                    </P>
                    <P>
                        <E T="03">Instructions:</E>
                         You must submit comments by one of the previously described methods to ensure that we receive, document, and consider them. Comments sent by any other method, to any other address or individual, or received after the end of the comment period, may not be considered. All comments received are a part of the public record and will generally be posted to 
                        <E T="03">https://www.regulations.gov</E>
                         without change. All Personal Identifying Information (for example, name, address, 
                        <E T="03">etc.</E>
                        ) voluntarily submitted by the commenter may be publicly accessible. Do not submit confidential business information or otherwise sensitive or protected information.
                    </P>
                    <P>NMFS will accept anonymous comments (enter “N/A” in the required fields if you wish to remain anonymous).</P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Adrienne Lohe, NMFS Office of Protected Resources, at 
                        <E T="03">Adrienne.Lohe@noaa.gov</E>
                         or 301-427-8442.
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">Background</HD>
                <P>
                    On May 14, 2024, we published a proposed rule to issue protective regulations under section 4(d) of the ESA for the threatened oceanic whitetip shark (
                    <E T="03">Carcharhinus longimanus</E>
                    ) (89 FR 41917). In that notification, we also announced a 60-day public comment period and the availability of a draft environmental assessment and an initial regulatory flexibility analysis.
                </P>
                <P>
                    On June 28, 2024, we received a request to extend the public comment period and hold public hearings for fishing communities in Hawai'i, the Territories of American Samoa and Guam, and the Commonwealth of the Northern Mariana Islands in order to better understand the potential impact of the proposed rule and for communities to provide comments on the proposed rule. On July 11, 2024, we published a 
                    <E T="04">Federal Register</E>
                     notification extending the comment period until September 15, 2024, and announcing that we would hold one or more public hearings on the proposed rule (89 FR 56847).
                    <PRTPAGE P="63394"/>
                </P>
                <P>
                    The proposed rule and other materials prepared in support of this action are available at: 
                    <E T="03">https://www.fisheries.noaa.gov/action/proposed-protective-regulations-oceanic-whitetip-shark.</E>
                </P>
                <HD SOURCE="HD1">Public Hearings</HD>
                <P>
                    One public hearing will be conducted in-person and one hearing will be conducted online as a Webex meeting, as specified in 
                    <E T="02">ADDRESSES</E>
                     above. The hearings will begin with a brief presentation by NMFS that gives an overview of the proposed protective regulations for the oceanic whitetip shark under section 4(d) of the ESA. After the presentation but before public comments, there will be a question and answer session during which members of the public may ask NMFS staff clarifying questions about the proposed protective regulations. Following the question and answer session, members of the public will have the opportunity to provide oral comments on the record regarding the proposed protective regulations. Members of the public will also have the opportunity to submit written comments at the hearings. Written comments may also be submitted at any time during the relevant public comment period as described above (see 
                    <E T="02">DATES</E>
                     and 
                    <E T="02">ADDRESSES</E>
                    ). All oral comments will be recorded, transcribed, and added to the public comment record for this proposed rule.
                </P>
                <AUTH>
                    <HD SOURCE="HED">Authority:</HD>
                    <P>
                        16 U.S.C. 1531 
                        <E T="03">et seq.</E>
                    </P>
                </AUTH>
                <SIG>
                    <DATED>Dated: July 30, 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-17152 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 3510-22-P</BILCOD>
        </PRORULE>
        <PRORULE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF COMMERCE</AGENCY>
                <SUBAGY>National Oceanic and Atmospheric Administration</SUBAGY>
                <CFR>50 CFR Part 648</CFR>
                <DEPDOC>[Docket No. 240726-0205]</DEPDOC>
                <RIN>RIN 0648-BN02</RIN>
                <SUBJECT>Fisheries of the Northeastern United States; Framework Adjustment 16 to the Mackerel, Squid, and Butterfish 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>Proposed rule; request for comments.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>
                        NMFS proposes regulations to implement Framework Adjustment 16 to the Mackerel, Squid, and Butterfish Fishery Management Plan. Framework 16 was developed by the Mid-Atlantic Fishery Management Council to establish a volumetric hold baseline for limited access 
                        <E T="03">Illex</E>
                         squid vessels, clarify 
                        <E T="03">Illex</E>
                         squid reporting requirements, and allow NMFS to collect information on the vessel processing type for 
                        <E T="03">Illex</E>
                         and longfin squid vessels. This action is necessary to restrict future increases in the capacity of the 
                        <E T="03">Illex</E>
                         squid fishery and to gain more accurate catch information to inform stock assessments.
                    </P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Comments must be received on or before Tuesday, August 20, 2024.</P>
                </EFFDATE>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>You may submit comments on this document, identified by NOAA-NMFS-2024-0060, by the following method:</P>
                    <P>
                        <E T="03">Electronic Submission:</E>
                         Submit all electronic public comments via the Federal e-Rulemaking Portal. Go to 
                        <E T="03">https://www.regulations.gov</E>
                         and enter NOAA-NMFS-2024-0060 in the Search box (
                        <E T="03">note:</E>
                         copying and pasting the FDMS Docket Number directly from this document may not yield search results). Click on the “Comment” icon, complete the required fields, and enter or attach your comments.
                    </P>
                    <P>
                        <E T="03">Instructions:</E>
                         Comments sent by any other method, to any other address or individual, or received after the end of the comment period, may not be considered by NMFS. All comments received are part of the public record and will generally be posted for public viewing on 
                        <E T="03">https://www.regulations.gov</E>
                         without change. All personal identifying information (
                        <E T="03">e.g.,</E>
                         name, address, etc.), confidential business information, or otherwise sensitive information submitted voluntarily by the sender will be publicly accessible. NMFS will accept anonymous comments (enter “N/A” in the required fields if you wish to remain anonymous).
                    </P>
                    <P>
                        The Mid-Atlantic Fishery Management Council prepared a Framework 16 document that describes the proposed action and other alternatives considered. Copies of this document including the preliminary Regulatory Impact Review, and the Regulatory Flexibility Act analysis, are available from: Dr. Christopher M. Moore, Executive Director, Mid-Atlantic Fishery Management Council, Suite 201, 800 North State Street, Dover, DE 19901. The document is also accessible via the internet at 
                        <E T="03">https://www.mafmc.org/supporting-documents.</E>
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Maria Fenton, Fishery Policy Analyst, (978) 281-9196, or 
                        <E T="03">maria.fenton@noaa.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">General Background</HD>
                <P>
                    In 2019, the Mid-Atlantic Fishery Management Council (Council) initiated Amendment 22 to the Mackerel, Squid, and Butterfish Fishery Management Plan (FMP). The intent of this action was to revise the number and type of 
                    <E T="03">Illex</E>
                     squid permits to address the negative effects from a perceived race to fish after the fishery closed in August or September from 2017 to 2021 when the annual quota had been caught. However, NMFS ultimately disapproved Amendment 22 on September 7, 2022, because the agency concluded that the record supporting the Council's proposal was not adequate or sufficient to support a decision to further restrict the number and types of permits in the 
                    <E T="03">Illex</E>
                     squid fishery in light of the Magnuson-Stevens Fishery Conservation and Management Act's (Magnuson-Stevens Act) National Standards, Amendment 22's stated purpose and need, and the goals and objectives of the FMP. Following the disapproval of Amendment 22, the Council decided to move forward with Framework 16 in order to address potential latent effort in the 
                    <E T="03">Illex</E>
                     squid fishery. The Council adopted proposed Framework 16 measures at its October 2023 meeting with the goal of capping fishing power in the 
                    <E T="03">Illex</E>
                     squid fishery.
                </P>
                <HD SOURCE="HD1">Proposed Measures</HD>
                <P>The Magnuson-Stevens Act requires NMFS to approve, partially approve, or disapprove measures proposed by the Council. The Magnuson-Stevens Act also requires NMFS to publish proposed rules for public comment after preliminarily determining whether the measures are consistent with applicable law. NMFS is proposing and seeking comment on the measures in Framework Adjustment 16, as recommended by the Council.</P>
                <HD SOURCE="HD2">1. Volumetric Hold Baseline for Limited Access Illex Squid Vessels</HD>
                <P>
                    This action proposes establishing a volumetric hold baseline for limited access 
                    <E T="03">Illex</E>
                     squid vessels in order to restrict future increases in capacity in this fishery. This would be a vessel baseline measurement in addition to the standard horsepower and length baseline measures required for all federally permitted vessels in the Greater Atlantic Region. If NMFS implements the proposed volumetric hold baseline requirement for limited access 
                    <E T="03">Illex</E>
                     squid permit holders through a subsequent final rule, a 
                    <PRTPAGE P="63395"/>
                    vessel's fish hold capacity measurement would need be certified by a qualified individual or entity as specified in the proposed regulation text. The fish hold capacity measurement would need to be submitted to NMFS and must include a signed certification by the qualified individual or entity within 12 months of the implementation of the final rule for this action. A similar volumetric hold baseline requirement was implemented for Tier 1 and Tier 2 Atlantic mackerel permit holders through Amendment 11 to the Mackerel, Squid, and Butterfish FMP in 2011 (76 FR 86842). If a vessel already possesses a volumetric hold baseline related to its Tier 1or Tier 2 Atlantic mackerel permit, that hold baseline could be incorporated for its limited access 
                    <E T="03">Illex</E>
                     squid permit as well.
                </P>
                <P>
                    If a limited access 
                    <E T="03">Illex</E>
                     squid permit is in Confirmation of Permit History (CPH) when fish hold capacity measurements are due, the default volumetric hold baseline for that CPH permit would be established based on the fish hold capacity measurement of the first replacement vessel greater than 20 ft (6.09 m) after the permit is removed from CPH (at which point the vessel's fish hold would have to be measured under the certification requirements before fishing under the permit). If a permit in CPH already had an existing fish hold capacity measurement for the vessel immediately preceding the permit's placement into CPH which met the measurement certification requirements, that fish hold capacity measurement could be used to establish a volumetric hold baseline for the 
                    <E T="03">Illex</E>
                     squid permit within the implementation period.
                </P>
                <P>
                    Replacement or upgraded vessels' re-certified fish hold capacity measurements could not exceed 110 percent of the permit's volumetric hold baseline (
                    <E T="03">i.e.,</E>
                     there could only be an increase of 10 percent beyond the volumetric hold baseline). The modified fish hold, or the fish hold of the replacement vessel, would have to be surveyed by a qualified surveyor as described in the proposed regulation text, unless the replacement vessel already had an appropriate fish hold capacity measurement on file with NMFS.
                </P>
                <HD SOURCE="HD2">2. Illex and Longfin Squid Processing Type</HD>
                <P>
                    This action also proposes to allow NMFS to collect information on the vessel processing type for 
                    <E T="03">Illex</E>
                     squid moratorium permits and Tier 1 longfin squid permits to help analyze the catch per unit effort for these fisheries. This information would be collected annually through the permit renewal application process. When these vessels submit their permit renewal application, they would need to indicate the vessel processing type (
                    <E T="03">i.e.,</E>
                     freezing at-sea, refrigerated sea water, or fresh/iced) that they primarily intend to use for the coming fishing year.
                </P>
                <HD SOURCE="HD2">3. Illex Squid Vessel Reporting Clarifications</HD>
                <P>
                    Finally, this action proposes to clarify that limited access 
                    <E T="03">Illex</E>
                     squid vessels are required to report daily via the vessel monitoring system (VMS) while on a declared 
                    <E T="03">Illex</E>
                     squid trip. This clarification was requested by the Council during the development of Amendment 22, but due to the disapproval of that action (for reasons that had nothing to do with this reporting adjustment), NMFS committed to address this clarification in this action instead. These daily catch reports would include the amount of retained and discarded 
                    <E T="03">Illex</E>
                     squid and total pounds of all fish retained. These reports need to be submitted in 24-hr intervals for each day and must be submitted by 0900 hr on the following day. Reports are required even if 
                    <E T="03">Illex</E>
                     squid caught that day have not yet been landed.
                </P>
                <HD SOURCE="HD1">Classification</HD>
                <P>Pursuant to section 304(b)(1)(A) of the Magnuson-Stevens Act, the NMFS Assistant Administrator has determined that this proposed rule is consistent with the Mackerel, Squid, and Butterfish FMP, other provisions of the Magnuson-Stevens Act, and other applicable law, subject to further consideration after public comment. In making a final determination, NMFS will take into account the data, views, and comments received during the comment period.</P>
                <P>This proposed rule has been determined to be not significant for purposes of Executive Order (E.O.) 12866.</P>
                <P>The Chief Counsel for Regulation of the Department of Commerce certified to the Chief Counsel for Advocacy of the Small Business Administration that this proposed rule, if adopted, would not have a significant economic impact on a substantial number of small entities.</P>
                <P>
                    The Council conducted an evaluation of the potential socioeconomic impacts of the proposed measures included in this rule. This proposed action would have the potential to affect vessels that hold limited access 
                    <E T="03">Illex</E>
                     and longfin squid permits. The analysis found that in 2023, there were 180 affiliates that held such permits, and 173 were small business entities and 7 were classified as large business entities. A business primarily engaged in commercial fishing is classified as a small business if it is independently owned and operated, is not dominant in its field of operation (including its affiliates), and has combined annual receipts not in excess of $11 million for all its affiliated operations worldwide (North American Industry Classification System Code 11411).
                </P>
                <P>
                    The primary impact for regulated entities involves the cost of a survey to document vessel hold size. This would affect the 46 
                    <E T="03">Illex</E>
                     squid permits that do not also have a similar requirement related to their existing Atlantic mackerel permit. The cost of a marine surveyor to measure a vessel's fish hold could cost approximately $10-$80 per foot of vessel length, which could range from $750-$6,000 for a 75-ft (22.9 m) vessel to $1,500-$12,000 for a 150-ft (45.7 m) vessel, depending on the surveyor, the boat design, and travel expenses. To the extent that surveys are already required for insurance purposes these costs may be already part of a vessel's operating costs. Given the overall costs of operating a fishing vessel, these one-time costs do not appear to be a significant impact on a substantial number of small entities. The vessel hold baseline upgrade restriction also limits how vessels may be re-configured or replaced. However, in the foreseeable future, a substantial number of small entities are unlikely to undergo extensive re-configurations or replacements as vessels are already restricted by their length overall and horsepower.
                </P>
                <P>The additional reporting requirements and annual reporting requirement for processing type should be a negligible addition to existing documentation requirements.</P>
                <P>This proposed rule contains collection-of-information requirements subject to review and approval by the Office of Management and Budget under the Paperwork Reduction Act (PRA). This rule revises the existing requirements for the collection of information 0648-0202, Greater Atlantic Region Permit Family of Forms.</P>
                <P>
                    This action proposes that limited access 
                    <E T="03">Illex</E>
                     squid vessels obtain a vessel hold measurement and submit that documentation to NMFS. There are 46 limited access 
                    <E T="03">Illex</E>
                     squid permits that do not currently have a vessel hold measurement on file with NMFS, the remaining 
                    <E T="03">Illex</E>
                     squid permits already have a vessel hold measurement on file due to the same requirement for their Tier 1 or Tier 2 Atlantic mackerel permit. The burden estimate for verifying vessel specifications is 3 hours 
                    <PRTPAGE P="63396"/>
                    per vessel therefore the total burden hours would be 138 hours. The hourly wage rate is $33.78 which would result in a wage burden increase of $4,661.64 (138 hours × $33.78).
                </P>
                <P>
                    The costs and burden hours for daily VMS reporting in the 
                    <E T="03">Illex</E>
                     squid fishery have already been calculated and received public comments through a previous action. Therefore the changes in this proposed rule are simply a clarification of existing regulatory requirements and do not need additional approval through the PRA. The reporting of the vessel processing type that is proposed in this action will be on the permit renewal form and will add an negligible additional burden amounting to no cost, therefore it also does not need additional approval through the PRA.
                </P>
                <P>
                    Public comment is sought regarding: whether this 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 burden estimate; 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, including through the use of automated collection techniques or other forms of information technology. Submit comments on these or any other aspect of the collection of information at 
                    <E T="03">www.reginfo.gov/public/do/PRAMain.</E>
                </P>
                <P>Notwithstanding any other provision of the law, no person is required to respond to, and no person shall be subject to penalty for failure to comply with, a collection of information subject to the requirements of the PRA, unless that collection of information displays a currently valid OMB Control Number.</P>
                <LSTSUB>
                    <HD SOURCE="HED">List of Subjects in 50 CFR Part 648</HD>
                    <P>Fisheries, Fishing, Reporting and recordkeeping requirements.</P>
                </LSTSUB>
                <SIG>
                    <DATED> Dated: July 29, 2024.</DATED>
                    <NAME>Samuel D. Rauch, III,</NAME>
                    <TITLE>Deputy Assistant Administrator for Regulatory Programs, National Marine Fisheries Service.</TITLE>
                </SIG>
                <P>For the reasons set out in the preamble, NMFS proposes to amend 50 CFR part 648 as follows:</P>
                <PART>
                    <HD SOURCE="HED">PART 648—FISHERIES OF THE NORTHEASTERN UNITED STATES</HD>
                </PART>
                <AMDPAR>1. The authority citation for part 648 continues to read as follows:</AMDPAR>
                <AUTH>
                    <HD SOURCE="HED">Authority: </HD>
                    <P>
                        16 U.S.C. 1801 
                        <E T="03">et seq.</E>
                    </P>
                </AUTH>
                <AMDPAR>2. In § 648.4, revise paragraphs (a)(5)(ii)(F) and (H), and add paragraphs (c)(2)(viii) and (ix) to read as follows:</AMDPAR>
                <SECTION>
                    <SECTNO>§ 648.4</SECTNO>
                    <SUBJECT>Vessel permits.</SUBJECT>
                    <STARS/>
                    <P>(a) * * *</P>
                    <P>(5) * * *</P>
                    <P>(ii) * * *</P>
                    <P>
                        (F) 
                        <E T="03">Upgraded vessel.</E>
                         See paragraph (a)(1)(i)(F) of this section. In addition for moratorium 
                        <E T="03">Illex</E>
                         squid permits, the replacement vessel's volumetric hold capacity may not exceed by more than 10 percent the volumetric fish hold capacity of the vessel's baseline specifications. The modified fish hold, or the fish hold of the replacement vessel, must be surveyed by a surveyor (accredited as in paragraph (a)(5)(ii)(H) of this section) and submitted to NMFS unless the replacement vessel already had an appropriate certification.
                    </P>
                    <STARS/>
                    <P>
                        (H) 
                        <E T="03">Vessel Baseline specifications.</E>
                    </P>
                    <P>
                        (
                        <E T="03">1</E>
                        ) The volumetric fish hold capacity of vessels with an 
                        <E T="03">Illex</E>
                         squid moratorium permit will be considered a vessel baseline specification in addition to the baseline specifications set forth in paragraph (a)(3)(i)(H) of this section. Volumetric fish hold capacity for vessels with moratorium 
                        <E T="03">Illex</E>
                         squid permit must be established not later than [DATE 395 DAYS AFTER DATE OF PUBLICATION OF FINAL RULE IN THE 
                        <E T="04">FEDERAL REGISTER</E>
                        ] if not previously established as specified in paragraphs (a)(5)(ii)(H)(
                        <E T="03">2</E>
                        ) of this section. The fish hold capacity measurement must be certified by one of the following qualified individuals or entities: An individual credentialed as a Certified Marine Surveyor with a fishing specialty by the National Association of Marine Surveyors (NAMS); an individual credentialed as an Accredited Marine Surveyor with a fishing specialty by the Society of Accredited Marine Surveyors (SAMS); employees or agents of a classification society approved by the Coast Guard pursuant to 46 U.S.C. 3316(c); the Maine State Sealer of Weights and Measures; a professionally-licensed and/or registered Marine Engineer; or a Naval Architect with a professional engineer license. The fish hold capacity measurement submitted to NMFS as required in this paragraph (a)(5)(ii)(H)(
                        <E T="03">1</E>
                        ) must include a signed certification by the individual or entity that completed the measurement, specifying how they meet the definition of a qualified individual or entity. If the vessel's permit suite does not include a Tier 1 or Tier 2 limited access Atlantic mackerel permit for which a volumetric fish hold capacity baseline has been established, the permit is not in CPH, or the volumetric hold measurement is not submitted as established by the date listed above, the subsequent moratorium 
                        <E T="03">Illex</E>
                         squid permit renewal application may be deemed incomplete until the volumetric hold measurement has been established.
                    </P>
                    <P>
                        (
                        <E T="03">2</E>
                        ) If an 
                        <E T="03">Illex</E>
                         squid vessel already possesses a volumetric hold baseline related to its Tier 1 or Tier 2 limited access Atlantic mackerel permit as specified in paragraph (a)(3)(iii)(H)(
                        <E T="03">1</E>
                        ), that measurement will automatically apply as a baseline specification for its 
                        <E T="03">Illex</E>
                         squid moratorium permit.
                    </P>
                    <P>
                        (
                        <E T="03">3</E>
                        ) If an 
                        <E T="03">Illex</E>
                         squid permit in CPH has an existing volumetric hold measurement pursuant to paragraph (a)(5)(ii)(H)(
                        <E T="03">1</E>
                        ) of this section for the vessel immediately preceding the permit's placement into CPH, that volumetric hold measurement may be used to establish a vessel hold baseline specification not later than [DATE 395 DAYS AFTER DATE OF PUBLICATION OF FINAL RULE IN THE 
                        <E T="04">FEDERAL REGISTER</E>
                        ]. In the alternative, if an 
                        <E T="03">Illex</E>
                         squid permit is in CPH, the volumetric hold capacity baseline may be the hold capacity of the first replacement vessel greater than 20 ft (6.09 m) after the permits are removed from CPH. Hold capacity for the replacement vessel must be measured pursuant to paragraph (a)(5)(ii)(H)(
                        <E T="03">1</E>
                        ) of this section.
                    </P>
                    <STARS/>
                    <P>(c) * * *</P>
                    <P>(2) * * *</P>
                    <P>
                        (viii) The owner of a vessel that has been issued a limited access 
                        <E T="03">Illex</E>
                         squid permit must submit a volumetric hold certification measurement, as described paragraph (a)(5)(ii)(H) of this section, otherwise the permit application for 2026 will be considered incomplete.
                    </P>
                    <P>
                        (ix) An application for limited access 
                        <E T="03">Illex</E>
                         squid and Tier 1 longfin squid permit must also contain the primary vessel processing type for the coming fishing year.
                    </P>
                    <STARS/>
                </SECTION>
                <AMDPAR>3. In § 648.7, add paragraph (b)(3)(iv) to read as follows:</AMDPAR>
                <SECTION>
                    <SECTNO>§ 648.7</SECTNO>
                    <SUBJECT>Record keeping and reporting requirements.</SUBJECT>
                    <STARS/>
                    <P>(b) * * *</P>
                    <P>(3) * * *</P>
                    <P>
                        (iv) 
                        <E T="03">Illex squid moratorium permit owners or operators.</E>
                         The owner or operator of a vessel issued an 
                        <E T="03">Illex</E>
                         squid moratorium permit must report catch (retained and discarded of 
                        <E T="03">Illex</E>
                         squid daily via VMS, unless exempted by the Regional Administrator. The report must include at least the following information, and any other information required by the Regional Administrator: Electronic Vessel Trip Report Trip 
                        <PRTPAGE P="63397"/>
                        Identifier; month, day, and year 
                        <E T="03">Illex</E>
                         squid was caught; total pounds of 
                        <E T="03">Illex</E>
                         squid retained and total pounds of all fish retained. Daily 
                        <E T="03">Illex</E>
                         squid VMS catch reports must be submitted in 24-hr intervals for each day and must be submitted by 0900 hr on the following day. Reports are required even if 
                        <E T="03">Illex</E>
                         squid caught that day have not yet been landed. This report does not exempt the owner or operator from other applicable reporting requirements of this section.
                    </P>
                    <STARS/>
                </SECTION>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17037 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 3510-22-P</BILCOD>
        </PRORULE>
    </PRORULES>
    <VOL>89</VOL>
    <NO>150</NO>
    <DATE>Monday, August 5, 2024</DATE>
    <UNITNAME>Notices</UNITNAME>
    <NOTICES>
        <NOTICE>
            <PREAMB>
                <PRTPAGE P="63398"/>
                <AGENCY TYPE="F">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 September 4, 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. 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">Food and Nutrition Service</HD>
                <P>
                    <E T="03">Title:</E>
                     Child Nutrition Programs: Community Eligibility Provision—Increasing Options for Schools.
                </P>
                <P>
                    <E T="03">OMB Control Number:</E>
                     0584-NEW.
                </P>
                <P>
                    <E T="03">Summary of Collection:</E>
                     The Child Nutrition rule, “Child Nutrition Programs: Community Eligibility Provision—Increasing Options for Schools (RIN 0584-AE93)” amends the regulations associated with the School Meals Program, which consists of the National School Lunch Program (NSLP) and the School Breakfast Program (SBP). The rule expands access to the Community Eligibility Program (CEP) by lowering the minimum identified student percentage participation threshold from 40 to 25 percent. This would give States and schools greater flexibility to choose to invest non-Federal funds so that no-cost meals can be offered to all enrolled students. Students who are classified as “identified students” are directly certified for free school meals and do not need to submit a household application. The proposal to lower the required identified student percentage expands access to the CEP, which provides more schools with an additional option for offering no-cost meals to students without requiring households to submit applications for the free and reduced-price meals. This rule amends existing information collection requirements that are currently approved in OMB Control Number 0584-0026 7 CFR part 245—Determining Eligibility for Free and Reduced Price Meals and Free Milk in Schools. Due to priorities for a number of high-profile rules and other workload priorities, FNS requested a new OMB control number for this collection. FNS intends to merge this new information collection into OMB Control Number 0584-0026 at a later date.
                </P>
                <P>
                    <E T="03">Need and Use of the Information:</E>
                     FNS collects information for this collection, which contains both mandatory and required to obtain or retain benefit requirements, from State administering agencies, local education agencies (LEAs), and households. The information collected from State agencies and LEAs ensures that eligibility determinations are verified. The information collected from households is used to determine eligibility for free and reduced-price meal benefits to verify eligibility determinations. FNS uses the information to verify that the States and LEAs are eligible to elect the CEP and to ensure compliance with the regulations. Households must meet requirements to receive free or reduced-price meal benefits.
                </P>
                <P>
                    <E T="03">Description of Respondents:</E>
                     State, Local, or Tribal Government; Individuals or Households.
                </P>
                <P>
                    <E T="03">Number of Respondents:</E>
                     3,485,189.
                </P>
                <P>
                    <E T="03">Frequency of Responses:</E>
                     Recordkeeping; Reporting: On occasion; Annually.
                </P>
                <P>
                    <E T="03">Total Burden Hours:</E>
                     626,375.
                </P>
                <SIG>
                    <NAME>Rachelle Ragland-Greene,</NAME>
                    <TITLE>Departmental Information Collection Clearance Officer.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2024-17140 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 3410-30-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">DEPARTMENT OF COMMERCE</AGENCY>
                <SUBAGY>Bureau of Economic Analysis</SUBAGY>
                <SUBJECT>Agency Information Collection Activities; Submission to the Office of Management and Budget (OMB) for Review and Approval; Comment Request; Services Surveys: BE-185, Quarterly Survey of Financial Services Transactions Between U.S. Financial Services Providers and Foreign Persons</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Bureau of Economic Analysis, Commerce.</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>The Department of Commerce, in accordance with the Paperwork Reduction Act of 1995 (PRA), invites the general public and other Federal agencies to comment on proposed and continuing information collections, which helps us assess the impact of our information collection requirements and minimize the public's reporting burden. The purpose of this notice is to allow for 60 days of public comment preceding submission of the collection to OMB.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>To ensure consideration, comments regarding this proposed information collection must be received on or before October 4, 2024.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Interested persons are invited to submit written comments to Christopher Stein, Chief, Services Surveys Branch, Bureau of Economic 
                        <PRTPAGE P="63399"/>
                        Analysis, by email to 
                        <E T="03">christopher.stein@bea.gov</E>
                         or 
                        <E T="03">PRAcomments@bea.gov.</E>
                         Please reference OMB Control Number 0608-0065 in the subject line of your comments. Do not submit Confidential Business Information or otherwise sensitive or protected information.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Requests for additional information or specific questions related to collection activities should be directed to Christopher Stein, Chief, Services Surveys Branch, Bureau of Economic Analysis; 301-278-9189; or via email at 
                        <E T="03">christopher.stein@bea.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">I. Abstract</HD>
                <P>The Quarterly Survey of Financial Services Transactions between U.S. Financial Services Providers and Foreign Persons (Form BE-185) is an ongoing survey that collects data from U.S. persons who engage in covered financial services transactions with foreign persons. A U.S. person means any individual, branch, partnership, associated group, association, estate, trust, corporation, or other organization (whether or not organized under the laws of any State), resident in the United States or subject to the jurisdiction of the United States. A U.S. person must report if they had combined sales of covered financial services to foreign persons that exceeded $20 million for the previous fiscal year or are expected to exceed that amount during the current fiscal year, or if they had combined purchases of covered financial services from foreign persons that exceeded $15 million for the previous fiscal year, or are expected to exceed that amount during the current fiscal year.</P>
                <P>The data are needed to monitor U.S. trade in financial services, to analyze the impact of these cross-border services on the U.S. and foreign economies, to compile and improve the U.S. economic accounts, to support U.S. commercial policy on trade in financial services, to conduct trade promotion, and to improve the ability of U.S. businesses to identify and evaluate market opportunities. The data are used in estimating the trade in financial services component of the U.S. international transactions accounts (ITAs) and national income and product accounts (NIPAs).</P>
                <P>The Bureau of Economic Analysis (BEA) is proposing a single modification to the survey beginning with reporting for the first quarter of 2025. BEA proposes to collect sales and purchases of underwriting and private placement services separately for equity and debt instruments. Currently, the BE-185 quarterly survey collects sales and purchases of underwriting services for these types of instruments as a single type of financial service. This proposed breakout by instrument type would better align these services transactions with other source data used to produce financial account transactions, which also include a debt and equity breakout. The breakout would thus allow for methodological improvements to the estimation of fees and commissions used to produce financial account transactions. Lastly, the change would align the service types collected on the BE-185 quarterly survey with those collected on the BE-180 Benchmark Survey of Financial Services Transactions between U.S. Financial Services Providers and Foreign Persons.</P>
                <P>BEA estimates there will be no change in the average number of burden hours per response because reporters are already providing these data on their survey as a combined service type. Additionally, BEA believes the data are readily available in their accounting records and reporters are familiar with the breakout since the BE-180 benchmark survey already collects the data separately for equity and debt instruments.</P>
                <P>BEA does not plan to change the exemption levels used for the current quarterly survey. The language in the instructions and definitions will be reviewed and adjusted as necessary to clarify survey requirements.</P>
                <HD SOURCE="HD1">II. Method of Collection</HD>
                <P>BEA contacts potential respondents by mail at the end of each quarter. Respondents would be required to file the completed BE-185 forms within 30 days after the end of each fiscal quarter that is not the final fiscal quarter of the year and within 45 days after the close of the final fiscal quarter of the year. Reports would be required from each U.S. person that had combined sales of covered financial services to foreign persons that exceeded $20 million for the previous fiscal year, or are expected to exceed that amount during the current fiscal year, or that had combined purchases of covered financial services from foreign persons that exceeded $15 million for the previous fiscal year, or that are expected to exceed that amount during the current fiscal year. Entities required to report will be contacted individually by BEA. Entities not contacted by BEA have no reporting responsibilities.</P>
                <P>
                    BEA offers its electronic filing option, the eFile system, for use in reporting on Form BE-185. For more information about eFile, go to 
                    <E T="03">www.bea.gov/efile.</E>
                     In addition, BEA posts all its survey forms and reporting instructions on its website, 
                    <E T="03">www.bea.gov/ssb.</E>
                     These may be downloaded, completed, printed, and submitted via fax or mail.
                </P>
                <HD SOURCE="HD1">III. Data</HD>
                <P>
                    <E T="03">OMB Control Number:</E>
                     0608-0065.
                </P>
                <P>
                    <E T="03">Form Number(s):</E>
                     BE-185.
                </P>
                <P>
                    <E T="03">Type of Review:</E>
                     Regular submission.
                </P>
                <P>
                    <E T="03">Affected Public:</E>
                     Business or other for-profit organizations.
                </P>
                <P>
                    <E T="03">Estimated Number of Respondents:</E>
                     2,860 annually (715 filed each quarter; 580 reporting mandatory data and 135 that would file exemption claims or voluntary responses).
                </P>
                <P>
                    <E T="03">Estimated Time per Response:</E>
                     10 hours is the average for the respondents filing mandatory data and 1 hour for those filing an exemption claim or voluntary response. Hours may vary considerably among respondents because of differences in company size and complexity.
                </P>
                <P>
                    <E T="03">Estimated Total Annual Burden Hours:</E>
                     23,740.
                </P>
                <P>
                    <E T="03">Estimated Total Annual Cost to Public:</E>
                     $0.
                </P>
                <P>
                    <E T="03">Respondent's Obligation:</E>
                     Mandatory.
                </P>
                <P>
                    <E T="03">Legal Authority:</E>
                     International Investment and Trade in Services Survey Act (Pub. L. 94-472, 22 U.S.C. 3101-3108, as amended), and section 5408 of the Omnibus Trade and Competitiveness Act of 1988.
                </P>
                <HD SOURCE="HD1">IV. Request for Comments</HD>
                <P>
                    <E T="03">Comments are invited on:</E>
                     (a) Whether the proposed collection of information is necessary for the proper performance of the functions of the Agency, including whether the information will have practical utility; (b) the accuracy of the Agency's estimate of the burden (including hours and cost) of the proposed collection of information; (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 information on respondents, including through the use of automated collection techniques or other forms of information technology.
                </P>
                <P>
                    Comments that you submit in response to this notice are a matter of public record. We will include or summarize each comment in our request to OMB to approve this Information Collection Request (ICR). Before including your address, phone number, email address, or other personal identifying information in your comment, you should be aware that your entire comment—including your personal identifying information—may be made publicly available at any time. While you may ask us in your comment 
                    <PRTPAGE P="63400"/>
                    to withhold your personal identifying information from public review, we cannot guarantee that we will be able to do so.
                </P>
                <SIG>
                    <NAME>Sheleen Dumas,</NAME>
                    <TITLE>Department PRA Clearance Officer, Office of the Under Secretary of Economic Affairs, Commerce Department.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17180 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 3510-06-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF COMMERCE</AGENCY>
                <SUBAGY>Economic Development Administration</SUBAGY>
                <SUBJECT>Notice of National Advisory Council on Innovation and Entrepreneurship Meeting; Correction</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Economic Development Administration, U.S. Department of Commerce.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of an open meeting; correction.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>
                        The Economic Development Administration published a document in the 
                        <E T="04">Federal Register</E>
                         on July 18, 2024, concerning a virtual public meeting of the National Advisory Council on Innovation and Entrepreneurship (NACIE). The document contained incorrect dates.
                    </P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>August 20, 2024, 2 p.m.-3 p.m. eastern time (ET).</P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Eric Smith, Office of the Assistant Secretary, 1401 Constitution Avenue NW, Room 78018, Washington, DC 20230; email: 
                        <E T="03">nacie@doc.gov;</E>
                         telephone: +1 202 482 8001. Please reference “NACIE August 2024 Meeting” in the subject line of your correspondence.
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">Correction</HD>
                <P>
                    In the 
                    <E T="04">Federal Register</E>
                     of July 18, 2024, in FR Doc. 2024-15753, on page 58331, in the first column, correct the 
                    <E T="02">DATES</E>
                     caption to read:
                </P>
                <SIG>
                    <DATED>Dated: July 31, 2024.</DATED>
                    <NAME>Eric Smith,</NAME>
                    <TITLE>Tech Hubs Program Director.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17198 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 3510-24-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF COMMERCE</AGENCY>
                <SUBAGY>International Trade Administration</SUBAGY>
                <DEPDOC>[A-570-084; C-570-085]</DEPDOC>
                <SUBJECT>Certain Quartz Surface Products From the People's Republic of China: Preliminary Results of 2021-2023 Antidumping Duty and 2021-2022 Countervailing Duty Administrative Reviews</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Enforcement and Compliance, International Trade Administration, Department of Commerce.</P>
                </AGY>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The U.S. Department of Commerce (Commerce) preliminarily determines that certain Malaysian exporters of certain quartz surface products (quartz surface products) continue to be ineligible to participate in the scope certification process established for the antidumping duty (AD) and countervailing duty (CVD) orders on quartz surface products from the People's Republic of China (China) for all imports of quartz surface products from Malaysia. Specifically, we find that these Malaysian exporters did not demonstrate that the quartz slab used to produce their exports to the United States was sourced from a country other than China. Interested parties are invited to comment on these preliminary results of review.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Applicable August 5, 2024.</P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Ajay Menon, AD/CVD Operations, Office IX, Enforcement and Compliance, International Trade Administration, U.S. Department of Commerce, 1401 Constitution Avenue NW, Washington, DC 20230; telephone: (202) 482-0208.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">Background</HD>
                <P>
                    On July 11, 2019, Commerce published the 
                    <E T="03">Orders</E>
                     on quartz surface products from China.
                    <SU>1</SU>
                    <FTREF/>
                     On September 11, 2023, we initiated AD and CVD administrative reviews of the 
                    <E T="03">Orders.</E>
                    <SU>2</SU>
                    <FTREF/>
                     On March 18, 2024, we extended the preliminary results of these reviews to no later than July 30, 2024.
                    <SU>3</SU>
                    <FTREF/>
                     On July 22, 2024, Commerce tolled certain deadlines in this administrative proceeding by seven days.
                    <SU>4</SU>
                    <FTREF/>
                     The deadline for the preliminary results is now August 6, 2024. For a complete description of the events that followed the initiation of these reviews, 
                    <E T="03">see</E>
                     the Preliminary Decision Memorandum.
                    <SU>5</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         
                        <E T="03">See Certain Quartz Surface Products from the People's Republic of China: Antidumping and Countervailing Duty Orders,</E>
                         84 FR 33053 (July 11, 2019) (
                        <E T="03">Orders</E>
                        ).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>2</SU>
                         
                        <E T="03">See Initiation of Antidumping and Countervailing Duty Administrative Reviews,</E>
                         88 FR 62322 (September 11, 2023).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>3</SU>
                         
                        <E T="03">See</E>
                         Memorandum, “Extension of Deadline for Preliminary Results of the Antidumping Duty Administrative Review; 2021-2023,” dated March 18, 2024; 
                        <E T="03">see also</E>
                         Memorandum, “Extension of Deadline for Preliminary Results of the Countervailing Duty Administrative Review; 2021-2022,” dated March 18, 2024.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>4</SU>
                         
                        <E T="03">See</E>
                         Memorandum, “Tolling of Deadlines for Antidumping and Countervailing Duty Proceedings,” dated July 22, 2024.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>5</SU>
                         
                        <E T="03">See</E>
                         Memorandum, “Decision Memorandum for the Preliminary Results of the 2021-2023 Antidumping Duty and 2021-2022 Countervailing Duty Administrative Reviews of Certain Quartz Surface Products from the People's Republic of China,” dated concurrently with, and hereby adopted by, this notice (Preliminary Decision Memorandum).
                    </P>
                </FTNT>
                <HD SOURCE="HD1">Scope of the Orders</HD>
                <P>
                    The products covered by the 
                    <E T="03">Orders</E>
                     are quartz surface products from China. For a complete description of the scope of the 
                    <E T="03">Order</E>
                    , 
                    <E T="03">see</E>
                     Preliminary Decision Memorandum.
                </P>
                <HD SOURCE="HD1">
                    Periods of Review 
                    <SU>6</SU>
                    <FTREF/>
                </HD>
                <FTNT>
                    <P>
                        <SU>6</SU>
                         
                        <E T="03">See Certain Quartz Surface Products from the People's Republic of China: Expansion of the Period of Review and Supplemental Opportunity To Request Administrative Review,</E>
                         89 FR 14055 (February 26, 2024); 
                        <E T="03">see also Certain Quartz Surface Products from the People's Republic of China: Expansion of the Period of Review and Supplemental Opportunity To Request Administrative Review; Correction,</E>
                         89 FR 17812 (March 12, 2024).
                    </P>
                </FTNT>
                <P>The period of review (POR) of the AD review is November 4, 2021, through June 30, 2023. The POR of the CVD review is November 4, 2021, through December 31, 2022.</P>
                <HD SOURCE="HD1">Methodology and Preliminary Results</HD>
                <P>Commerce is conducting these reviews in accordance with section 751 of the Tariff Act of 1930, as amended (the Act). We preliminarily determine that Bada Industries, Karina Stone, Unique Stone Sdn. Bhd. (Unique Stone), and Universal Quartz, have not demonstrated that the quartz slab used to produce their Malaysian exports to the United States during the POR was sourced from a country other than China. As a result, we preliminary find that Bada Industries, Karina Stone, Unique Stone, and Universal Quartz continue to be ineligible to participate in the certification process for quartz surface products from Malaysia.</P>
                <P>
                    The Preliminary Decision Memorandum is a public document and is on file electronically via Enforcement and Compliance's Antidumping and Countervailing Duty Centralized Electronic Service System (ACCESS). ACCESS is available to registered users at 
                    <E T="03">https://access.trade.gov.</E>
                     In addition, a complete version of the Preliminary Decision Memorandum can be accessed directly at 
                    <E T="03">https://access.trade.gov/public/FRNoticesListLayout.aspx.</E>
                     A list 
                    <PRTPAGE P="63401"/>
                    of the topics discussed in the Preliminary Decision Memorandum is attached as an appendix to this notice.
                </P>
                <HD SOURCE="HD1">Assessment Rates</HD>
                <P>
                    Upon issuing the final results, Commerce shall determine, and U.S. Customs and Border Protection (CBP) shall assess, antidumping and countervailing duties on all appropriate entries covered by this review.
                    <SU>7</SU>
                    <FTREF/>
                     For the period November 4, 2021, through December 31, 2022, we will instruct CBP to liquidate any entries for the exporters under review at 371.47 percent, the combination of the China-wide rate established in the AD investigation and the all-others rate established in the CVD investigation. For the period of January 1, 2023, through June 30, 2023, we will instruct CBP to liquidate any entries for the exporters under review at 326.15 percent, the China-wide rate established in the AD investigation.
                </P>
                <FTNT>
                    <P>
                        <SU>7</SU>
                         
                        <E T="03">See</E>
                         19 CFR 351.106(c)(2).
                    </P>
                </FTNT>
                <P>
                    In accordance with sections 751(a)(2)(C) and 751(a)(1) of the Act, the final results of these reviews shall be the basis for the assessment of antidumping and countervailing duties on entries of merchandise covered by the review and for future deposits of estimated duties, where applicable. Commerce intends to issue assessment instructions to CBP no earlier than 35 days after the date of publication of the final results of these reviews in the 
                    <E T="04">Federal Register</E>
                    . If a timely summons is filed at the U.S. Court of International Trade, the assessment instructions will direct CBP not to liquidate relevant entries until the time for parties to file a request for a statutory injunction has expired (
                    <E T="03">i.e.,</E>
                     within 90 days of publication).
                </P>
                <HD SOURCE="HD1">Cash Deposit Requirements—AD</HD>
                <P>
                    The following AD cash deposit requirements will be effective upon publication of the final results of review for all shipments of subject merchandise from China entered, or withdrawn from warehouse, for consumption on, or after, the publication date of the final results of review, as provided for by section 751(a)(2)(C) of the Act: (1) for the Malaysian exporters subject to this review (
                    <E T="03">i.e.,</E>
                     Bada Industries, Karina Stone, Unique Stone, and Universal Quartz), Commerce will instruct CBP to require AD cash deposits equal to the current China-wide rate (
                    <E T="03">i.e.,</E>
                     326.15 percent); (2) for previously investigated or reviewed exporter of subject merchandise that have a separate rate, the cash deposit rate will continue to be the exporter's existing cash deposit rate; (3) for all Chinese exporters of subject merchandise that do not have a separate rate, the cash deposit rate will be the rate established for the China-wide entity, 
                    <E T="03">i.e.,</E>
                     326.15 percent; 
                    <SU>8</SU>
                    <FTREF/>
                     and (4) for all exporters of subject merchandise that are not located in China and that are not eligible for a separate rate, the cash deposit rate will be the rate applicable to the Chinese exporter(s) that supplied that non-Chinese exporter. These deposit requirements, when imposed, shall remain in effect until further notice.
                </P>
                <FTNT>
                    <P>
                        <SU>8</SU>
                         
                        <E T="03">See Order,</E>
                         78 FR at 21592.
                    </P>
                </FTNT>
                <HD SOURCE="HD1">Cash Deposit Requirements—CVD</HD>
                <P>
                    In accordance with section 751(a)(2)(C) of the Act, for the exporters subject to this review (
                    <E T="03">i.e.,</E>
                     Bada Industries, Karina Stone, Unique Stone, and Universal Quartz), Commerce also intends, upon publication of the final results, to instruct CBP to collect cash deposits of estimated countervailing duties for the companies subject to this review at current all-others rate (
                    <E T="03">i.e.,</E>
                     45.32 percent). For all non-reviewed firms, CBP will continue to collect cash deposits of estimated countervailing duties at the all-others rate or the most recent company-specific rate applicable to the company, as appropriate. These cash deposit requirements, when imposed, shall remain in effect until further notice.
                </P>
                <HD SOURCE="HD1">Verification</HD>
                <P>Because we preliminary determine that the exporters under review are not eligible to participate in the certification process, we will not conduct verification.</P>
                <HD SOURCE="HD1">Public Comment</HD>
                <P>
                    Pursuant to 19 CFR 351.309(c), interested parties may submit case briefs to Commerce no later than 30 days after the date of publication of this notice.
                    <SU>9</SU>
                    <FTREF/>
                     Rebuttal briefs, limited to issues raised in the case briefs, may be filed no later than five days after the date for filing case briefs.
                    <SU>10</SU>
                    <FTREF/>
                     Interested parties who submit case briefs or rebuttal briefs in this proceeding must submit: (1) a table of contents listing each issue; and (2) a table of authorities.
                    <SU>11</SU>
                    <FTREF/>
                     All case and rebuttal briefs should be filed using ACCESS.
                    <SU>12</SU>
                    <FTREF/>
                     An electronically-filed document must be received successfully in its entirety by ACCESS by 5:00 p.m. Eastern Time on the established deadline. Parties should file their case and rebuttal briefs on the records of both the AD and CVD administrative reviews.
                </P>
                <FTNT>
                    <P>
                        <SU>9</SU>
                         
                        <E T="03">See</E>
                         19 CFR 351.303 (for general filing requirements).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>10</SU>
                         
                        <E T="03">See</E>
                         19 CFR 351.309(d); 
                        <E T="03">see also Administrative Protective Order, Service, and Other Procedures in Antidumping and Countervailing Duty Proceedings,</E>
                         88 FR 67069, 67077 (September 29, 2023) (
                        <E T="03">APO and Service Final Rule</E>
                        ).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>11</SU>
                         
                        <E T="03">See</E>
                         19 CFR 351.309(c)(2) and (d)(2).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>12</SU>
                         
                        <E T="03">See</E>
                         19 CFR 351.303.
                    </P>
                </FTNT>
                <P>
                    As provided under 19 CFR 351.309(c)(2) and (d)(2), in prior proceedings we have encouraged interested parties to provide an executive summary of their brief that should be limited to five pages total, including footnotes. In these reviews, we instead request that interested parties provide at the beginning of their briefs a public, executive summary for each issue raised in their briefs. Further, we request that interested parties limit their executive summary of each issue to no more than 450 words, not including citations. We intend to use the executive summaries as the basis of the comment summaries included in the issues and decision memorandum that will accompany the final results in these reviews. We request that interested parties include footnotes for relevant citations in the executive summary of each issue. Note that Commerce has amended certain of its requirements pertaining to the service of documents in 19 CFR 351.303(f).
                    <SU>13</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>13</SU>
                         
                        <E T="03">See APO and Service Final Rule.</E>
                    </P>
                </FTNT>
                <P>
                    Pursuant to 19 CFR 351.310(c), interested parties who wish to request a hearing must submit a written request to the Assistant Secretary for Enforcement and Compliance, filed electronically via ACCESS within 30 days after the date of publication of this notice. Requests should contain: (1) the party's name, address, and telephone number; (2) the number of participants; and (3) a list of issues to be discussed. Issues raised in the hearing will be limited to those raised in the respective case briefs. If a request for a hearing is made, Commerce will notify interested parties of the time and date for the hearing.
                    <SU>14</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>14</SU>
                         
                        <E T="03">See</E>
                         19 CFR 351.310(d).
                    </P>
                </FTNT>
                <HD SOURCE="HD1">Final Results</HD>
                <P>
                    Commerce intends to issue the final results of these administrative reviews, including the results of its analysis raised in any written briefs, not later than 120 days after the publication of these preliminary results in the 
                    <E T="04">Federal Register</E>
                    , unless otherwise extended.
                    <SU>15</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>15</SU>
                         
                        <E T="03">See</E>
                         section 751(a)(3)(A) of the Act.
                    </P>
                </FTNT>
                <HD SOURCE="HD1">Notification to Importers</HD>
                <P>
                    This notice also serves as a preliminary reminder to importers of their responsibility under 19 CFR 351.402(f)(2) to file a certificate regarding the reimbursement of antidumping and/or countervailing duties prior to liquidation of the 
                    <PRTPAGE P="63402"/>
                    relevant entries during this review period. Failure to comply with this requirement could result in Commerce's presumption that reimbursement of antidumping and/or countervailing duties occurred and the subsequent assessment of double antidumping duties, and/or an increase in the amount of antidumping duties by the amount of the countervailing duties.
                </P>
                <HD SOURCE="HD1">Notification to Interested Parties</HD>
                <P>We are issuing and publishing these preliminary results in accordance with sections 751(a)(1) and 777(i)(1) of the Act, 19 CFR 351.213, and 19 CFR 351.221(b)(4).</P>
                <SIG>
                    <DATED>Dated: July 29, 2024.</DATED>
                    <NAME>Ryan Majerus,</NAME>
                    <TITLE>Deputy Assistant Secretary for Policy and Negotiations, performing the non-exclusive functions and duties of the Assistant Secretary for Enforcement and Compliance.</TITLE>
                </SIG>
                <HD SOURCE="HD1">Appendix</HD>
                <EXTRACT>
                    <HD SOURCE="HD1">List of Topics Discussed in the Preliminary Decision Memorandum</HD>
                    <FP SOURCE="FP-2">I. Summary</FP>
                    <FP SOURCE="FP-2">II. Background</FP>
                    <FP SOURCE="FP-2">III. Periods of Review</FP>
                    <FP SOURCE="FP-2">
                        IV. Scope of the 
                        <E T="03">Orders</E>
                    </FP>
                    <FP SOURCE="FP-2">V. Analysis of Certification Eligibility</FP>
                    <FP SOURCE="FP-2">VI. Recommendation</FP>
                </EXTRACT>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17171 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 3510-DS-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF COMMERCE</AGENCY>
                <SUBAGY>International Trade Administration</SUBAGY>
                <DEPDOC>[A-508-814]</DEPDOC>
                <SUBJECT>Brass Rod From Israel: Final Affirmative Determination of Sales at Less Than Fair Value</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Enforcement and Compliance, International Trade Administration, U.S. Department of Commerce.</P>
                </AGY>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The U.S. Department of Commerce (Commerce) determines that brass rod from Israel is being, or is likely to be, sold in the United States at less than fair value (LTFV). The period of investigation (POI) is April 1, 2022, through March 31, 2023.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Applicable August 5, 2024.</P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Andrew Hart, AD/CVD Operations, Office II, Enforcement and Compliance, International Trade Administration, U.S. Department of Commerce, 1401 Constitution Avenue NW, Washington, DC 20230; telephone: (202) 482-1058.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">Background</HD>
                <P>
                    On December 14, 2023, Commerce published in the 
                    <E T="04">Federal Register</E>
                     its preliminary affirmative determination in the LTFV investigation of brass rod from Israel and invited interested parties to comment on the 
                    <E T="03">Preliminary Determination.</E>
                    <SU>1</SU>
                    <FTREF/>
                     On December 7, 2023, due to the outbreak of war in Israel and the consequent impacts on all parts of the country, and in consideration of the November 21, 2023 letters submitted by the Government of Israel,
                    <SU>2</SU>
                    <FTREF/>
                     Commerce tolled all deadlines for this investigation for a period of 90 days.
                    <SU>3</SU>
                    <FTREF/>
                     On July 22, 2024, Commerce tolled certain deadlines in this proceeding by seven days.
                    <SU>4</SU>
                    <FTREF/>
                     The deadline for the final determination is now July 29, 2024.
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         
                        <E T="03">See Brass Rod from Israel: Preliminary Affirmative Determination of Sales at Less Than Fair Value, Postponement of Final Determination, and Extension of Provisional Measures,</E>
                         88 FR 86632 (December 14, 2023) (
                        <E T="03">Preliminary Determination</E>
                        ), and accompanying Preliminary Decision Memorandum.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>2</SU>
                         
                        <E T="03">See</E>
                         Government of Israel's Letter, “Comments on Prelim Determination,” dated November 21, 2023; and Embassy of Israel's Letter, “Upcoming Preliminary Decision,” dated November 21, 2023.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>3</SU>
                         
                        <E T="03">See</E>
                         Memorandum, “Tolling of Deadlines in the Less-Than-Fair Value Investigation of Brass Rod from Israel,” dated December 7, 2023.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>4</SU>
                         
                        <E T="03">See</E>
                         Memorandum, “Tolling of Deadlines for Antidumping and Countervailing Duty Proceedings,” dated July 22, 2024.
                    </P>
                </FTNT>
                <P>
                    A summary of the events that occurred since Commerce published its 
                    <E T="03">Preliminary Determination,</E>
                     as well as a full discussion of the issues raised by parties for this final determination, may be found in the Issues and Decision Memorandum.
                    <SU>5</SU>
                    <FTREF/>
                     The Issues and Decision Memorandum is a public document and is on file electronically via Enforcement and Compliance's Antidumping and Countervailing Duty Centralized Electronic Service System (ACCESS). ACCESS is available to registered users at 
                    <E T="03">https://access.trade.gov.</E>
                     In addition, a complete version of the Issues and Decision Memorandum can be accessed directly at 
                    <E T="03">https://access.trade.gov/public/FRNoticesListLayout.aspx.</E>
                </P>
                <FTNT>
                    <P>
                        <SU>5</SU>
                         
                        <E T="03">See</E>
                         Memorandum, “Decision Memorandum for the Final Affirmative Determination in the Less-Than-Fair-Value Investigation of Brass Rod from Israel,” dated concurrently with, and hereby adopted by, this notice (Issues and Decision Memorandum).
                    </P>
                </FTNT>
                <HD SOURCE="HD1">Scope of the Investigation</HD>
                <P>
                    The product covered by this investigation is brass rod from Israel. For a complete description of the scope of this investigation, 
                    <E T="03">see</E>
                     Appendix I to this notice.
                </P>
                <HD SOURCE="HD1">Scope Comments</HD>
                <P>
                    During this investigation, Commerce received scope comments from parties. Commerce issued a Preliminary Scope Decision Memorandum to address these comments and set aside a period for parties to address scope issues in scope-specific case and rebuttal briefs.
                    <SU>6</SU>
                    <FTREF/>
                     We did not receive timely comments from any interested parties on the Preliminary Scope Decision Memorandum. Thus, we did not make any changes to the scope of the investigation from the scope published in the 
                    <E T="03">Preliminary Determination</E>
                     and included in Appendix I.
                    <SU>7</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>6</SU>
                         
                        <E T="03">See</E>
                         Memorandum, “Preliminary Scope Decision Memorandum,” dated September 25, 2023 (Preliminary Scope Decision Memorandum).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>7</SU>
                         
                        <E T="03">See Brass Rod from India: Final Affirmative Countervailing Duty Determination,</E>
                         88 FR 87407 (December 18, 2023); 
                        <E T="03">see also Preliminary Determination.</E>
                    </P>
                </FTNT>
                <HD SOURCE="HD1">Verification</HD>
                <P>
                    As provided in section 782(i)(1) of the Tariff Act of 1930, as amended (the Act), in April and May 2024, we verified the sales and cost information submitted by Finkelstein Metals Ltd. (Finkelstein) for use in our final determination. We used standard verification procedures, including an examination of relevant sales and accounting records, and original source documents provided by Finkelstein.
                    <SU>8</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>8</SU>
                         
                        <E T="03">See</E>
                         Memorandum, “Verification of the Cost Response of Finkelstein Metals Ltd. in the Less-Than-Fair-Value Investigation of Brass Rods from Israel,” dated June 5, 2024; Memorandum, “U.S. Virtual Verification of the Response of Finkelstein Metals USA Inc. in the Less-Than-Fair-Value Investigation of Brass Rod from Israel,” dated June 11, 2024; and Memorandum, “Verification of the Sales Response of Finkelstein Metals Ltd. in the Antidumping Duty Investigation of Brass Rod from the Israel,” dated June 11, 2024.
                    </P>
                </FTNT>
                <HD SOURCE="HD1">Analysis of Comments Received</HD>
                <P>All issues raised in the case and rebuttal briefs submitted by interested parties in this investigation are addressed in the Issues and Decision Memorandum. A list of the issues addressed in the Issues and Decision Memorandum is attached as Appendix II to this notice.</P>
                <HD SOURCE="HD1">Changes Since the Preliminary Determination</HD>
                <P>
                    We made certain changes to the margin calculation for Finkelstein, since the 
                    <E T="03">Preliminary Determination.</E>
                    <SU>9</SU>
                    <FTREF/>
                     For a discussion of these changes, 
                    <E T="03">see</E>
                     the Issues and Decision Memorandum.
                </P>
                <FTNT>
                    <P>
                        <SU>9</SU>
                         
                        <E T="03">See</E>
                         Memorandum, “Analysis for the Final Determination for Finkelstein Metals Ltd.,” dated concurrently with this notice.
                    </P>
                </FTNT>
                <HD SOURCE="HD1">All-Others Rate</HD>
                <P>
                    Section 735(c)(5)(A) of the Act provides that the estimated weighted-average dumping margin for all other exporters and producers not individually examined shall be an amount equal to the weighted average of the estimated weighted-average dumping margins established for exporters and producers individually 
                    <PRTPAGE P="63403"/>
                    investigated, excluding any zero and 
                    <E T="03">de minimis</E>
                     margins, and any margins determined entirely under section 776 of the Act.
                </P>
                <P>
                    In this investigation, Commerce calculated an individual estimated weighted-average dumping margin for Finkelstein, the only individually examined exporter/producer. Because the only individually calculated dumping margin is not zero, 
                    <E T="03">de minimis,</E>
                     or based entirely on facts otherwise available, the estimated weighted-average dumping margin calculated for Finkelstein is the margin assigned to all other producers and exporters, pursuant to section 735(c)(5)(A) of the Act.
                </P>
                <HD SOURCE="HD1">Final Determination</HD>
                <P>Commerce determines that the following estimated weighted-average dumping margins exist for the period, April 1, 2022, through March 31, 2023:</P>
                <GPOTABLE COLS="3" OPTS="L2,tp0,i1" CDEF="s50,12,r50">
                    <TTITLE/>
                    <BOXHD>
                        <CHED H="1">Exporter/producer</CHED>
                        <CHED H="1">
                            Weighted-
                            <LI>average</LI>
                            <LI>dumping</LI>
                            <LI>margin</LI>
                            <LI>(percent)</LI>
                        </CHED>
                        <CHED H="1">
                            Cash deposit rate
                            <LI>(adjusted for subsidy offset(s)) </LI>
                            <LI>(percent)</LI>
                        </CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">Finkelstein Metals Ltd</ENT>
                        <ENT>19.48</ENT>
                        <ENT>Not Applicable.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">All Others</ENT>
                        <ENT>19.48</ENT>
                        <ENT>Not Applicable.</ENT>
                    </ROW>
                </GPOTABLE>
                <HD SOURCE="HD1">Disclosure</HD>
                <P>
                    Commerce intends to disclose the calculations performed in connection with this final determination to interested parties within five days of any public announcement or, if there is no public announcement, within five days of the publication of the notice in the 
                    <E T="04">Federal Register</E>
                    , in accordance with 19 CFR 351.224(b).
                </P>
                <HD SOURCE="HD1">Suspension of Liquidation</HD>
                <P>
                    As a result of our 
                    <E T="03">Preliminary Determination,</E>
                     and pursuant to sections 733(d)(2) and 733(d)(1)(B) of the Act and 19 CFR 351.205(d), Commerce instructed U.S. Customs and Border Protection (CBP) to collect cash deposits and suspend liquidation of entries of subject merchandise as described in the scope of the investigation, entered, or withdrawn from warehouse, for consumption on or after December 14, 2024, the date of publication of the 
                    <E T="03">Preliminary Determination</E>
                     in the 
                    <E T="04">Federal Register</E>
                    . In accordance with section 733(d)(2)(b) of the Act, we instructed CBP to discontinue the suspension of liquidation of all entries of subject merchandise entered or withdrawn from warehouse on or after June 11, 2024, but to continue the suspension of liquidation of all entries of subject merchandise on or before June 10, 2024.
                </P>
                <P>
                    Pursuant to sections 736(a), 735(c)(1)(B)(ii) of the Act and 19 CFR 351.210(d), in the event of an affirmative injury determination by the U.S. International Trade Commission (ITC), we will issue an antidumping duty order, reinstate the suspension of liquidation, and require a cash deposit of estimated antidumping duties for such entries of subject merchandise in the amounts indicated above. Effective on the date of publication in the 
                    <E T="04">Federal Register</E>
                     of the ITC's final determination, Commerce will instruct CBP to require a cash deposit equal to the estimated weighted-average dumping margin or the estimated all others rate as follows: (1) the cash deposit rate for the companies listed above will be equal to the company-specific estimated weighted-average dumping margin determined in this final determination; (2) if the exporter is not a respondent identified above but the producer is, then the cash deposit rate will be equal to the company-specific estimated weighted-average dumping margin established for that producer of the subject merchandise; and (3) the cash deposit rate for all other producers and exporters will be equal to the all-others estimated weighted-average dumping margin.
                </P>
                <P>Commerce normally adjusts cash deposits for estimated antidumping duties by the amount of export subsidies countervailed in a companion CVD proceeding when CVD provisional measures are in effect. Accordingly, where Commerce made a final affirmative determination for countervailable export subsidies, Commerce has offset the estimated weighted-average dumping margin by the appropriate CVD rate. Any such adjusted cash deposit rate may be found in the “Final Determination” section above.</P>
                <P>Pursuant to section 735(c)(2) of the Act, if the ITC determines that material injury, or threat of material injury, does not exist, this proceeding will be terminated, and all estimated duties deposited or securities posted as a result of the suspension of liquidation will be refunded or canceled.</P>
                <HD SOURCE="HD1">U.S. International Trade Commission Notification</HD>
                <P>In accordance with section 735(d) of the Act, we will notify the ITC of its final affirmative determination of sales at LTFV. Because Commerce's final determination is affirmative, in accordance with section 735(b)(2) of the Act, the ITC will make its final determination as to whether the domestic industry in the United States is materially injured, or threatened with material injury, by reason of imports or sales (or the likelihood of sales) for importation of brass rod from Israel no later than 45 days after this final determination. If the ITC determines that such injury does not exist, this proceeding will be terminated, and all cash deposits posted will be refunded and suspension of liquidation will be lifted. If the ITC determines that such injury does exist, Commerce will issue an antidumping duty order directing CBP to assess, upon further instruction by Commerce, antidumping duties on all imports of the subject merchandise, entered, or withdrawn from warehouse, for consumption on or after the effective date of the suspension of liquidation, as discussed above in the “Suspension of Liquidation” section.</P>
                <HD SOURCE="HD1">Administrative Protective Order</HD>
                <P>This notice serves as a final reminder to parties subject to an administrative protective order (APO) of their responsibility concerning the return or destruction of proprietary information disclosed under APO in accordance with 19 CFR 351.305(a)(3), which continues to govern business proprietary information in this segment of the proceeding. Timely written notification of the return or destruction of APO materials, or conversion to judicial protective order, is hereby requested. Failure to comply with the regulations and the terms of an APO is a violation subject to sanction.</P>
                <HD SOURCE="HD1">Notification to Interested Parties</HD>
                <P>This determination and this notice are issued and published in accordance with sections 735(d) and 777(i) of the Act, and 19 CFR 351.210(c).</P>
                <SIG>
                    <PRTPAGE P="63404"/>
                    <DATED>Dated: July 29, 2024.</DATED>
                    <NAME>Ryan Majerus,</NAME>
                    <TITLE>Deputy Assistant Secretary for Policy and Negotiations, performing the non-exclusive functions and duties of the Assistant Secretary for Enforcement and Compliance.</TITLE>
                </SIG>
                <HD SOURCE="HD1">Appendix I</HD>
                <EXTRACT>
                    <HD SOURCE="HD1">Scope of the Investigation</HD>
                    <P>The products covered by this investigation are brass rod and bar (brass rod), which is defined as leaded, low-lead, and no-lead solid brass made from alloys such as, but not limited to the following alloys classified under the Unified Numbering System (UNS) as C27450, C27451, C27460, C34500, C35000, C35300, C35330, C36000, C36300, C37000, C37700, C48500, C67300, C67600, and C69300, and their international equivalents.</P>
                    <P>
                        The brass rod subject to this investigation has an actual cross-section or outside diameter greater than 0.25 inches but less than or equal to 12 inches. Brass rod cross-sections may be round, hexagonal, square, or octagonal shapes as well as special profiles (
                        <E T="03">e.g.,</E>
                         angles, shapes), including hollow profiles.
                    </P>
                    <P>
                        Standard leaded brass rod covered by the scope contains, by weight, 57.0-65.0 percent copper; 0.5-3.0 percent lead; no more than 1.3 percent iron; and at least 15 percent zinc. No-lead or low-lead brass rod covered by the scope contains by weight 59.0-76.0 percent copper; 0-1.5 percent lead; no more than 0.35 percent iron; and at least 15 percent zinc. Brass rod may also include other chemical elements (
                        <E T="03">e.g.,</E>
                         nickel, phosphorous, silicon, tin, etc.).
                    </P>
                    <P>Brass rod may be in straight lengths or coils. Brass rod covered by this investigation may be finished or unfinished, and may or may not be heated, extruded, pickled, or cold-drawn. Brass rod may be produced in accordance with ASTM B16, ASTM B124, ASTM B981, ASTM B371, ASTM B453, ASTM B21, ASTM B138, and ASTM B927, but such conformity to an ASTM standard is not required for the merchandise to be included within the scope.</P>
                    <P>Excluded from the scope of this investigation is brass ingot, which is a casting of unwrought metal unsuitable for conversion into brass rod without remelting, that contains, by weight, at least 57.0 percent copper and 15.0 percent zinc.</P>
                    <P>The merchandise covered by this investigation is currently classifiable under subheadings 7407.21.9000, 7407.21.7000, and 7407.21.1500 of the Harmonized Tariff Schedule of the United States (HTSUS). Products subject to the scope may also enter under HTSUS subheadings 7403.21.0000, 7407.21.3000, and 7407.21.5000. The HTSUS subheadings and UNS alloy designations are provided for convenience and customs purposes. The written description of the scope of the investigation is dispositive.</P>
                </EXTRACT>
                <HD SOURCE="HD1">Appendix II</HD>
                <EXTRACT>
                    <HD SOURCE="HD1">List of Topics Discussed in the Issues and Decision Memorandum</HD>
                    <FP SOURCE="FP-2">I. Summary</FP>
                    <FP SOURCE="FP-2">II. Background</FP>
                    <FP SOURCE="FP-2">
                        III. Changes from the 
                        <E T="03">Preliminary Determination</E>
                    </FP>
                    <FP SOURCE="FP-2">IV. Discussion of the Issue</FP>
                    <FP SOURCE="FP1-2">Comment: Whether to Grant a Level of Trade Adjustment</FP>
                    <FP SOURCE="FP-2">V. Recommendation</FP>
                </EXTRACT>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17173 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 3510-DS-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF COMMERCE</AGENCY>
                <SUBAGY>International Trade Administration</SUBAGY>
                <DEPDOC>[A-570-106, C-570-107]</DEPDOC>
                <SUBJECT>Wooden Cabinets and Vanities and Components Thereof From the People's Republic of China: Final Scope Determination, Certification Requirements, and Recission of Circumvention Inquiries on the Antidumping and Countervailing Duty Orders; Correction</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Enforcement and Compliance, International Trade Administration, Department of Commerce.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice; correction.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>
                        The U.S. Department of Commerce (Commerce) published a notice in the 
                        <E T="04">Federal Register</E>
                         of July 17, 2024, in which Commerce implemented a certification regime. This notice did not correctly state the grace period for parties to certify wooden cabinets and vanities and components thereof (wooden cabinets) shipped prior to the publication of the 
                        <E T="04">Federal Register</E>
                         Notice.
                    </P>
                </SUM>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Michael Romani, AD/CVD Operations, Office I, Enforcement and Compliance, International Trade Administration, U.S. Department of Commerce, 1401 Constitution Avenue NW, Washington, DC 20230; telephone: (202) 482-0198.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">Background</HD>
                <P>
                    On July 17, 2024, Commerce published in the 
                    <E T="04">Federal Register</E>
                     the final scope determinations, certification requirements, and recission of circumvention inquiries on the antidumping and countervailing duty orders on wooden cabinets.
                    <SU>1</SU>
                    <FTREF/>
                     In that notice, Commerce did not correctly describe the grace period for goods that were shipped before the implementation of the certification regime in the text, although this was alluded to in the importer and exporter appendices. Additionally, Commerce did not explain that entries accompanied by the appropriate certification documentation do not require suspension of liquidation or cash deposits.
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         
                        <E T="03">See Wooden Cabinets and Vanities and Components Thereof from the People's Republic of China: Final Scope Determination, Certification Requirements, and Rescission of Circumvention Inquiries on the Antidumping and countervailing Duty Orders,</E>
                         89 FR 58110 (July 17, 2024).
                    </P>
                </FTNT>
                <HD SOURCE="HD1">Correction</HD>
                <P>
                    In the 
                    <E T="04">Federal Register</E>
                     of July 17, 2024, in FR Doc 2024-15681, on page 58111, in the second column, correct the text in the first full paragraph by adding the following sentence to the end of the paragraph: “For entries accompanied by a certification, no suspension of liquidation or cash deposits are required.” The corrected paragraph is attached to this notice as Appendix I.
                </P>
                <P>
                    In addition, in the 
                    <E T="04">Federal Register</E>
                     of July 17, 2024, in FR Doc 2024-15681, on page 58112, in the second column, correct the third paragraph under the “Certification Requirements for Malaysia and Vietnam” by inserting the following sentence at the end of the paragraph: “Note: For merchandise shipped within 45 days of the date of the publication of this 
                    <E T="04">Federal Register</E>
                     notice (
                    <E T="03">i.e.,</E>
                     07/17/2024), the certification requirements should be met as soon as practicable, but no later than 8/31/2024.”
                </P>
                <P>
                    Additionally, in the 
                    <E T="04">Federal Register</E>
                     of July 17, 2024, in FR Doc 2024-15681, on page 58113, in Appendix II, at paragraph N. of the Importer Certification, and on page 58114 in Appendix III at paragraph K. of the Exporter Certification, correct the language in each appendix to state: “within 45 days of the date of publication of this notice in the 
                    <E T="04">Federal Register</E>
                    .” The corrected paragraphs are attached to this notice as Appendix II.
                </P>
                <HD SOURCE="HD1">Notification to Interested Parties</HD>
                <P>This notice is issued and published in accordance with sections 781(b) and 777(i) of the Tariff Act of 1930, as amended, 19 CFR 351.225(h), 19 CFR 351.226(f)(6), and 19 CFR 351.228.</P>
                <SIG>
                    <DATED>Dated: July 30, 2024.</DATED>
                    <NAME>Ryan Majerus,</NAME>
                    <TITLE>Deputy Assistant Secretary for Policy and Negotiations, performing the non-exclusive functions and duties of the Assistant Secretary for Enforcement and Compliance.</TITLE>
                </SIG>
                <HD SOURCE="HD1">Appendix I</HD>
                <EXTRACT>
                    <HD SOURCE="HD1">Continuation of Suspension of Liquidation in Accordance With Final Scope Ruling</HD>
                    <P>
                        Specifically, if an importer of wooden cabinets from Malaysia or Vietnam claims that the wooden cabinet was not produced using Scenarios 1, 2, or 3, then the importer and exporter must meet the certification and documentation requirements described in Appendices II and III. An exporter of wooden cabinets in Malaysia or Vietnam claiming its wooden cabinet were not produced using the 
                        <PRTPAGE P="63405"/>
                        Chinese wooden cabinet input scenarios subject to these inquiries must prepare and maintain an Exporter Certification and documentation supporting the Exporter Certification (
                        <E T="03">see</E>
                         Appendix III). In addition, importers of such wooden cabinets must prepare and maintain an Importer Certification (
                        <E T="03">see</E>
                         Appendix II) and documentation supporting the Importer Certification. Further, the importer must also maintain a copy of the Exporter Certification and relevant supporting documentation from its exporter of wooden cabinets in Malaysia or Vietnam that were not produced using any of the Chinese wooden cabinet input scenarios subject to these inquiries. For entries accompanied by a certification, no suspension of liquidation or cash deposits are required.
                    </P>
                </EXTRACT>
                <HD SOURCE="HD1">Appendix II</HD>
                <EXTRACT>
                    <HD SOURCE="HD1">Certification Requirements for Malaysia and Vietnam</HD>
                    <P>
                        Exporters are required to complete and maintain the applicable exporter certification and provide the importer with a copy of that certification and all supporting documentation (
                        <E T="03">e.g.,</E>
                         invoice, purchase order, production records, 
                        <E T="03">etc.</E>
                        ) Except for the entries described below, the exporter certification must be completed, signed, and dated by the time of shipment of the relevant entries. The exporter certification should be completed by the party selling wooden cabinets assembled in Malaysia to the United States. Note: For merchandise shipped within 45 days of 07/17/2024, the certification requirements should be met as soon as practicable, but no later than 8/31/2024.
                    </P>
                    <HD SOURCE="HD1">Importer Certification</HD>
                    <P>
                        N. This certification was completed by the time of filing the entry summary or within 45 days of the date of publication of this notice in the 
                        <E T="04">Federal Register</E>
                        .
                    </P>
                    <HD SOURCE="HD1">Exporter Certification</HD>
                    <P>
                        K. This certification was completed at the time of shipment or within 45 days of the date of publication of this notice in the 
                        <E T="04">Federal Register</E>
                        .
                    </P>
                </EXTRACT>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17165 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 3510-DS-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF COMMERCE</AGENCY>
                <SUBAGY>International Trade Administration</SUBAGY>
                <SUBJECT>Quarterly Update to Annual Listing of Foreign Government Subsidies on Articles of Cheese Subject to an In-Quota Rate of Duty</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Enforcement and Compliance, International Trade Administration, Department of Commerce.</P>
                </AGY>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Applicable August 5, 2024.</P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Samuel Brummitt, AD/CVD Operations, Office III, Enforcement and Compliance, International Trade Administration, U.S. Department of Commerce, 1401 Constitution Ave. NW, Washington, DC 20230, telephone: (202) 482-7851.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    On May 9, 2024, the U.S. Department of Commerce (Commerce), pursuant to section 702(h) of the Trade Agreements Act of 1979 (as amended) (the Act), published the quarterly update to the annual listing of foreign government subsidies on articles of cheese subject to an in-quota rate of duty covering the period October 1, 2023, through December 31, 2023.
                    <SU>1</SU>
                    <FTREF/>
                     In the 
                    <E T="03">Fourth Quarter 2023 Update,</E>
                     we requested that any party that had information on foreign government subsidy programs that benefited articles of cheese subject to an in-quota rate of duty submit such information to Commerce.
                    <SU>2</SU>
                    <FTREF/>
                     We received no comments, information, or requests for consultation from any party.
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         
                        <E T="03">See Quarterly Update to Annual Listing of Foreign Government Subsidies on Articles of Cheese Subject to an In-Quota Rate of Duty,</E>
                         89 FR 39588 (May 9, 2024) (
                        <E T="03">Fourth Quarter 2023 Update</E>
                        ).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>2</SU>
                         
                        <E T="03">Id.</E>
                    </P>
                </FTNT>
                <P>Pursuant to section 702(h) of the Act, we hereby provide Commerce's update of subsidies on articles of cheese that were imported during the period January 1, 2024, through March 31, 2024. The appendix to this notice lists the country, the subsidy program or programs, and the gross and net amounts of each subsidy for which information is currently available.</P>
                <P>
                    Commerce will incorporate additional programs which are found to constitute subsidies, and additional information on the subsidy programs listed, as the information is developed. Commerce encourages any person having information on foreign government subsidy programs which benefit articles of cheese subject to an in-quota rate of duty to submit such information in writing through the Federal eRulemaking Portal at 
                    <E T="03">https://www.regulations.gov,</E>
                     Docket No. ITA-2020-0005, “Quarterly Update to Cheese Subject to an In-Quota Rate of Duty.” The materials in the docket will not be edited to remove identifying or contact information, and Commerce cautions against including any information in an electronic submission that the submitter does not want publicly disclosed. Attachments to electronic comments will be accepted in Microsoft Word, Excel, or Adobe PDF formats only. All comments should be addressed to the Assistant Secretary for Enforcement and Compliance, U.S. Department of Commerce, 1401 Constitution Avenue NW, Washington, DC 20230.
                </P>
                <P>This determination and notice are in accordance with section 702(a) of the Act.</P>
                <SIG>
                    <DATED>Dated: July 30, 2024.</DATED>
                    <NAME>Ryan Majerus,</NAME>
                    <TITLE>Deputy Assistant Secretary for Policy and Negotiations, performing the non-exclusive functions and duties of the Assistant Secretary for Enforcement and Compliance.</TITLE>
                </SIG>
                <HD SOURCE="HD1">
                    Appendix
                    <FTREF/>
                </HD>
                <FTNT>
                    <P>
                        <SU>3</SU>
                         Defined in 19 U.S.C. 1677(5).
                    </P>
                    <P>
                        <SU>4</SU>
                         Defined in 19 U.S.C. 1677(6).
                    </P>
                    <P>
                        <SU>5</SU>
                         The 27 member states of the European Union are: Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, and Sweden.
                    </P>
                </FTNT>
                <GPOTABLE COLS="4" OPTS="L2,i1" CDEF="s50,r50,15,15">
                    <TTITLE>Subsidy Programs on Cheese Subject to an In-Quota Rate of Duty</TTITLE>
                    <BOXHD>
                        <CHED H="1">Country</CHED>
                        <CHED H="1">Program(s)</CHED>
                        <CHED H="1">
                            Gross 
                            <SU>3</SU>
                             subsidy
                            <LI>($/lb)</LI>
                        </CHED>
                        <CHED H="1">
                            Net 
                            <SU>4</SU>
                             subsidy
                            <LI>($/lb)</LI>
                        </CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">
                            27 European Union Member States 
                            <SU>5</SU>
                        </ENT>
                        <ENT>European Union Restitution Payments</ENT>
                        <ENT>$0.00</ENT>
                        <ENT>$0.00</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Canada</ENT>
                        <ENT>Export Assistance on Certain Types of Cheese</ENT>
                        <ENT>0.47</ENT>
                        <ENT>0.47</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Norway</ENT>
                        <ENT>Indirect (Milk) Subsidy</ENT>
                        <ENT>0.00</ENT>
                        <ENT>0.00</ENT>
                    </ROW>
                    <ROW RUL="n,n,s">
                        <ENT I="22"> </ENT>
                        <ENT>Consumer Subsidy</ENT>
                        <ENT>0.00</ENT>
                        <ENT>0.00  </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT>Total</ENT>
                        <ENT>0.00</ENT>
                        <ENT>0.00</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Switzerland</ENT>
                        <ENT>Deficiency Payments</ENT>
                        <ENT>0.00</ENT>
                        <ENT>0.00</ENT>
                    </ROW>
                </GPOTABLE>
                <PRTPAGE P="63406"/>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17166 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 3510-DS-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF COMMERCE</AGENCY>
                <SUBAGY>International Trade Administration</SUBAGY>
                <DEPDOC>[A-423-813, A-301-803, A-549-833]</DEPDOC>
                <SUBJECT>Citric Acid and Certain Citrate Salts From Belgium, Colombia, and Thailand: Continuation of Antidumping Duty Orders</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Enforcement and Compliance, International Trade Administration, Department of Commerce.</P>
                </AGY>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>As a result of the determinations by the U.S. Department of Commerce (Commerce) and the U.S. International Trade Commission (ITC) that revocation of the antidumping duty (AD) orders on citric acid and certain citrate salts (citric acid) from Belgium, Colombia, and Thailand would likely lead to the continuation or recurrence of dumping and material injury to an industry in the United States, Commerce is publishing a notice of continuation of these AD orders.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Applicable July 19, 2024.</P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Deborah Cohen, AD/CVD Operations, Office III, Enforcement and Compliance, International Trade Administration, U.S. Department of Commerce, 1401 Constitution Avenue NW, Washington, DC 20230; telephone: (202) 482-4521.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">Background</HD>
                <P>
                    On July 25, 2018, Commerce published in the 
                    <E T="04">Federal Register</E>
                     the AD orders on citric acid from Belgium, Colombia, and Thailand.
                    <SU>1</SU>
                    <FTREF/>
                     On June 1, 2023, the ITC instituted,
                    <SU>2</SU>
                    <FTREF/>
                     and Commerce initiated,
                    <SU>3</SU>
                    <FTREF/>
                     the first sunset review of the 
                    <E T="03">Orders,</E>
                     pursuant to section 751(c) of the Tariff Act of 1930, as amended (the Act). As a result of its reviews, Commerce determined that revocation of the 
                    <E T="03">Orders</E>
                     would likely lead to the continuation or recurrence of dumping and, therefore, notified the ITC of the magnitude of the margin of dumping likely to prevail should the 
                    <E T="03">Orders</E>
                     be revoked.
                    <SU>4</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         
                        <E T="03">See Citric Acid and Certain Citrate Salts from Belgium, Colombia and Thailand: Antidumping Duty Orders,</E>
                         83 FR 35214 (July 25, 2018) (
                        <E T="03">Orders</E>
                        ).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>2</SU>
                         
                        <E T="03">See Citric Acid and Certain Citrate Salts from Belgium, Colombia, and Thailand; Institution of Five-Year Reviews,</E>
                         88 FR 35923 (June 1, 2023).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>3</SU>
                         
                        <E T="03">See</E>
                         Initiation of Five-Year (Sunset) Reviews, 88 FR 35832 (June 1, 2023).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>4</SU>
                         
                        <E T="03">See Citric Acid and Certain Citrate Salts from Belgium: Final Results of the Sunset Review of the Antidumping Duty Order,</E>
                         88 FR 88361 (December 21, 2023); and 
                        <E T="03">Citric Acid and Certain Citrate Salts from Thailand and Colombia: Final Results of the Expedited First Sunset Reviews of the Antidumping Duty Orders,</E>
                         88 FR 67239 (September 29, 2023).
                    </P>
                </FTNT>
                <P>
                    On July 19, 2024, the ITC published its determination, pursuant to sections 751(c) and 752(a) of the Act, that revocation of the 
                    <E T="03">Orders</E>
                     would likely lead to continuation or recurrence of material injury to an industry in the United States within a reasonably foreseeable time.
                    <SU>5</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>5</SU>
                         
                        <E T="03">See Citric Acid and Certain Citrate Salts from Belgium, Colombia, and Thailand Determination,</E>
                         89 FR 58764 (July 19, 2024).
                    </P>
                </FTNT>
                <HD SOURCE="HD1">Scope of the Orders</HD>
                <P>
                    The merchandise covered by these 
                    <E T="03">Orders</E>
                     includes all grades and granulation sizes of citric acid, sodium citrate, and potassium citrate in their unblended forms, whether dry or in solution, and regardless of packaging type. For a complete description of the scope of the 
                    <E T="03">Orders,</E>
                      
                    <E T="03">see</E>
                     the appendix to this notice.
                </P>
                <HD SOURCE="HD1">Continuation of the Orders</HD>
                <P>
                    As a result of the determinations by Commerce and the ITC that revocation of the 
                    <E T="03">Orders</E>
                     would likely lead to continuation or recurrence of dumping and material injury to an industry in the United States, pursuant to section 751(d)(2) of the Act, Commerce hereby orders the continuation of the 
                    <E T="03">Orders.</E>
                     U.S. Customs and Border Protection will continue to collect AD cash deposits at the rates in effect at the time of entry for all imports of subject merchandise.
                </P>
                <P>
                    The effective date of the continuation of the 
                    <E T="03">Orders</E>
                     will be July 19, 2024.
                    <SU>6</SU>
                    <FTREF/>
                     Pursuant to section 751(c)(2) of the Act and 19 CFR 351.218(c)(2), Commerce intends to initiate the next five-year reviews of the 
                    <E T="03">Orders</E>
                     not later than 30 days prior to fifth anniversary of the date of the last determination by the ITC.
                </P>
                <FTNT>
                    <P>
                        <SU>6</SU>
                         
                        <E T="03">Id.</E>
                    </P>
                </FTNT>
                <HD SOURCE="HD1">Administrative Protective Order (APO)</HD>
                <P>This notice also serves as a final reminder to parties subject to an APO of their responsibility concerning the return or destruction of proprietary information disclosed under APO in accordance with 19 CFR 351.305(a)(3), which continues to govern business proprietary information in this segment of the proceeding. Timely written notification of the return or destruction of APO materials, or conversion to judicial protective order, is hereby requested. Failure to comply with the regulations and terms of an APO is a violation which is subject to sanction.</P>
                <HD SOURCE="HD1">Notification to Interested Parties</HD>
                <P>These five-year (sunset) reviews and this notice are in accordance with sections 751(c) and 751(d)(2) of the Act and published in accordance with section 777(i) of the Act, and 19 CFR 351.218(f)(4).</P>
                <SIG>
                    <DATED>Dated: July 30, 2024.</DATED>
                    <NAME>Ryan Majerus,</NAME>
                    <TITLE>Deputy Assistant Secretary for Policy and Negotiations, performing the non-exclusive functions and duties of the Assistant Secretary for Enforcement and Compliance. </TITLE>
                </SIG>
                <HD SOURCE="HD1">Appendix</HD>
                <EXTRACT>
                    <HD SOURCE="HD1">Scope of the Orders</HD>
                    <P>
                        The merchandise covered by these 
                        <E T="03">Orders</E>
                         includes all grades and granulation sizes of citric acid, sodium citrate, and potassium citrate in their unblended forms, whether dry or in solution, and regardless of packaging type. The scope also includes blends of citric acid, sodium citrate, and potassium citrate; as well as blends with other ingredients, such as sugar, where the unblended form(s) of citric acid, sodium citrate, and potassium citrate constitute 40 percent or more, by weight, of the blend.
                    </P>
                    <P>The scope also includes all forms of crude calcium citrate, including dicalcium citrate monohydrate, and tricalcium citrate tetrahydrate, which are intermediate products in the production of citric acid, sodium citrate, and potassium citrate.</P>
                    <P>The scope includes the hydrous and anhydrous forms of citric acid, the dihydrate and anhydrous forms of sodium citrate, otherwise known as citric acid sodium salt, and the monohydrate and monopotassium forms of potassium citrate. Sodium citrate also includes both trisodium citrate and monosodium citrate which are also known as citric acid trisodium salt and citric acid monosodium salt, respectively.</P>
                    <P>The scope does not include calcium citrate that satisfies the standards set forth in the United States Pharmacopeia and has been mixed with a functional excipient, such as dextrose or starch, where the excipient constitutes at least 2 percent, by weight, of the product.</P>
                    <P>Citric acid and sodium citrate are classifiable under 2918.14.0000 and 2918.15.1000 of the Harmonized Tariff Schedule of the United States (HTSUS), respectively. Potassium citrate and crude calcium citrate are classifiable under 2918.15.5000 and, if included in a mixture or blend, 3824.99.9397 of the HTSUS. Blends that include citric acid, sodium citrate, and potassium citrate are classifiable under 3824.99.9397 of the HTSUS. Although the HTSUS subheadings are provided for convenience and customs purposes, the written description of the merchandise is dispositive.</P>
                </EXTRACT>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17172 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 3510-DS-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <PRTPAGE P="63407"/>
                <AGENCY TYPE="S">DEPARTMENT OF COMMERCE</AGENCY>
                <SUBAGY>International Trade Administration</SUBAGY>
                <SUBJECT>Advisory Committee on Supply Chain Competitiveness: Notice of Public 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 open meeting.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>This notice sets forth the schedule and proposed topics of discussion for the upcoming public meeting of the Advisory Committee on Supply Chain Competitiveness (Committee).</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>The meeting will be held on September 11, 2024, from 10 a.m. to 1 p.m., eastern daylight time (EDT).</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>The meeting will be held in the U.S. Department of Commerce, 1401 Constitution Avenue NW, Research Library (Room 1894), Washington, DC 20230. The meeting will also be held via Zoom.</P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Richard Boll, Designated Federal Officer, Office of Supply Chain Services, International Trade Administration at Email: 
                        <E T="03">richard.boll@trade.gov,</E>
                         phone 571-331-0098.
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P/>
                <P>
                    <E T="03">Background:</E>
                     The Committee was established under the discretionary authority of the Secretary of Commerce and in accordance with the Federal Advisory Committee Act (5 U.S.C. app.). It provides advice to the Secretary of Commerce on the necessary elements of a comprehensive policy approach to supply chain competitiveness and on regulatory policies and programs and investment priorities that affect the competitiveness of U.S. supply chains. For more information about the Committee visit: 
                    <E T="03">https://www.trade.gov/acscc.</E>
                </P>
                <P>
                    <E T="03">Matters to Be Considered:</E>
                     Committee members are expected to continue discussing the major competitiveness-related topics raised at the previous Committee meetings, including supply chain resilience and congestion; trade and competitiveness; freight movement and policy; trade innovation; regulatory issues; finance and infrastructure; and workforce development. The agenda may change to accommodate other Committee business. The Office of Supply Chain Services will post the final detailed agenda on its website, 
                    <E T="03">https://www.trade.gov/acscc.</E>
                     The video with closed captioning of the meeting will also be posted on the Committee website.
                </P>
                <P>
                    The meeting is open to the public and press on a first-come, first-served basis. Space is limited. Please contact Richard Boll, Designated Federal Officer, at 
                    <E T="03">richard.boll@trade.gov,</E>
                     for participation information.
                </P>
                <SIG>
                    <NAME>Heather Sykes,</NAME>
                    <TITLE>Director, Office of Supply Chain Services.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17245 Filed 8-2-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>Notice of Scope Rulings</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Enforcement and Compliance, International Trade Administration, Department of Commerce.</P>
                </AGY>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The U.S. Department of Commerce (Commerce) hereby publishes a list of scope rulings and circumvention determinations made during the period January 1, 2024, through March 31, 2024. We intend to publish future lists after the close of the next calendar quarter.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Applicable August 5, 2024.</P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Marcia E. Short, AD/CVD Operations, Customs Liaison Unit, Enforcement and Compliance, International Trade Administration, U.S. Department of Commerce, 1401 Constitution Avenue NW, Washington, DC 20230; telephone: 202-482-1560.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">Background</HD>
                <P>
                    Commerce regulations provide that it will publish in the 
                    <E T="04">Federal Register</E>
                     a list of scope rulings on a quarterly basis.
                    <SU>1</SU>
                    <FTREF/>
                     Our most recent notification of scope rulings published on June 4, 2024.
                    <SU>2</SU>
                    <FTREF/>
                     This current notice covers all scope rulings made by Enforcement and Compliance between January 1, 2024, and March 31, 2024.
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         
                        <E T="03">See</E>
                         19 CFR 351.225(o).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>2</SU>
                         
                        <E T="03">See Notice of Scope Rulings,</E>
                         89 FR 47896 (June 4, 2024).
                    </P>
                </FTNT>
                <HD SOURCE="HD2">Scope Rulings Made January 1, 2024, Through March 31, 2024</HD>
                <HD SOURCE="HD3">Mexico</HD>
                <HD SOURCE="HD3">A-201-805: Certain Circular Welded Non-Alloy Steel Pipe From Mexico</HD>
                <P>
                    <E T="03">Requestor:</E>
                     Productos Laminados de Monterrey S.A. de C.V and PLM Steel Tubes LLC. Six types of circular welded non-alloy steel pipe that are exported from the United States to Mexico for further processing before re-entry into the United States, produced by Productos Laminados de Monterrey S.A. de C.V and PLM Steel Tubes LLC, are not covered the scope of the antidumping duty order on certain circular welded non-alloy steel pipe from Mexico because the country of origin is not Mexico: March 12, 2024.
                </P>
                <HD SOURCE="HD3">People's Republic of China (China)</HD>
                <HD SOURCE="HD3">A-570-910 and C-570-911: Circular Welded Carbon Quality Steel Pipe From China</HD>
                <P>
                    <E T="03">Requestor:</E>
                     NEXTracker LLC. Fifteen models of torque tubes are not covered by the scope of the antidumping and countervailing duty orders on circular welded carbon quality steel pipe from China because they are mechanical tubes which are excluded from the scope: January 8, 2024.
                </P>
                <HD SOURCE="HD3">A-570-135 and C-570-136: Certain Chassis and Subassemblies Thereof From China</HD>
                <P>
                    <E T="03">Requestor:</E>
                     Pitts Enterprises, Inc. dba Dorsey Intermodal. Finished chassis from Vietnam containing Chinese-origin subassemblies are covered by the antidumping duty and countervailing duty orders on certain chassis and subassemblies thereof from China. Subassemblies from China finished or unfinished and whether assembled or unassembled are subject covered by the orders: January 10, 2024.
                </P>
                <HD SOURCE="HD3">A-570-890: Woodend Bedroom Furniture From China</HD>
                <P>
                    <E T="03">Requestor:</E>
                     Zinus, Inc. Seven models of beds are not covered by the scope of the antidumping duty order on wooden bedroom furniture from China because they are not made substantially of wood products: January 11, 2024.
                </P>
                <HD SOURCE="HD3">A-570-106 and C-570-107: Wooden Cabinets and Vanities and Components Thereof From China</HD>
                <P>
                    <E T="03">Requestor:</E>
                     Nanjing Kaylang Co., Ltd. Cabinets and vanities made from phragmites are covered by the antidumping and countervailing duty orders on wooden cabinets and vanities and components thereof from China because the scope clearly includes “engineered wood products” and we determine phragmite particle board to be an engineered wood product: January 12, 2024.
                </P>
                <HD SOURCE="HD3">A-570-084 and C-570-085: Certain Quartz Surface Products From China</HD>
                <P>
                    <E T="03">Requestor:</E>
                     Vanguard Trading Company, LLC (VTC). Fritech, a waste mineral-based surface product, is predominantly made of silica and, therefore, within the scope of the AD and CVD orders. Quartz surface products consist of slabs and other surfaces created from a mixture of 
                    <PRTPAGE P="63408"/>
                    materials that includes predominately silica (
                    <E T="03">e.g.,</E>
                     quartz, quartz powder, cristobalite) as well as a resin binder (
                    <E T="03">e.g.,</E>
                     an unsaturated polyester). The scope of the orders only includes products where the silica content is greater than any other single material by actual weight. While the scope language does not explicitly address waste mineral-based surface product, synthetic stone surfaces that are primarily silica by actual weight are explicitly covered. Accordingly, for purposes of our analysis in this case, we examined whether fritech is predominantly silica or predominately composed of something else. Based on our analysis, and taking into account lab reports and VTC's patent information, we find fritech to be predominantly silica and, therefore, subject to the scope of the orders: January 25, 2024.
                </P>
                <HD SOURCE="HD3">A-570-981 and C-570-982: Utility Scale Wind Towers From China</HD>
                <P>
                    <E T="03">Requestor:</E>
                     Orsted A/S, Orsted North America Inc. The sources enumerated in 19 CFR 351.225(k)(1) demonstrate that monopiles, 
                    <E T="03">i.e.,</E>
                     steel cylinders that serve as a foundation for offshore wind turbines, are not covered by the scope of the antidumping duty and countervailing duty orders on utility scale wind towers from China: February 6, 2024.
                </P>
                <HD SOURCE="HD3">A-570-881: Malleable Iron Pipe Fittings From China</HD>
                <P>
                    <E T="03">Requestor:</E>
                     JL International, Inc. Certain types of electrical conduit fittings (electrical conduit bodies, electrical conduit nipples, and electrical conduit couplings and connectors) are not covered by the scope of the antidumping duty order on certain malleable iron pipe fittings from China because they are designed and manufactured to conform to different industry codes and standards than malleable iron pipe fittings, and are not suitable for use in oil, gas, or sprinkler applications. This final scope ruling is applicable on a country-wide basis, regardless of foreign producer, exporter, or importer: February 8, 2024.
                </P>
                <HD SOURCE="HD3">A-570-082 and C-570-083: Certain Steel Wheels From China</HD>
                <P>
                    <E T="03">Requestor:</E>
                     Asia Wheel Co., Ltd. Asia Wheel's steel truck wheels are not covered by the scope of the antidumping duty and countervailing duty orders on certain steel wheels from China because the wheels themselves, as well as their primary rim and disc component parts, are all produced in Thailand: February 9, 2024.
                </P>
                <HD SOURCE="HD3">A-570-831: Fresh Garlic From China</HD>
                <P>
                    <E T="03">Requestor:</E>
                     Export Packers Company Limited. Export Packers IQF cooked garlic cloves are subject to the scope of the antidumping duty order on fresh garlic from China because the garlic cloves: (1) have certain physical characteristics that differ from the subject merchandise but are not considered “prepared” by “heat processing”; (2) have similar expectations of use as subject merchandise due to the marketing and advertising of the product; (3) are used as a food or seasoning which is the same use as subject merchandise; (4) are sold to retailers through the same channel of trade (
                    <E T="03">i.e.,</E>
                     other seasonings, flavorings, and food ingredients) as the subject merchandise; and (5) are marketed to retailers in the same manner as subject merchandise: February 21, 2024.
                </P>
                <HD SOURCE="HD3">A-570-831: Fresh Garlic From China</HD>
                <P>
                    <E T="03">Requestor:</E>
                     Roland Foods, LLC. Roland Foods' whole garlic cloves (in brine) are not covered by the scope of the antidumping duty order on fresh garlic from China because they are preserved by the addition of other ingredients. Moreover, as a second, alternative basis, Roland Foods' whole garlic cloves in brine are not subject to the order because they are mechanically harvested and not used as fresh produce: March 1, 2024.
                </P>
                <HD SOURCE="HD3">A-570-073 and C-570-074: Common Alloy Aluminum Sheet From China</HD>
                <P>
                    <E T="03">Requestor:</E>
                     Century Metals &amp; Supplies, Inc. Aluminum coil produced from 8011 alloy aluminum, having a thickness of 6.3 millimeters or less, but greater than 0.2 millimeters, is not covered by the scope of the antidumping duty and countervailing duty orders on common alloy aluminum sheet from China because it is not produced from an in-scope aluminum alloy series: March 12, 2024.
                </P>
                <HD SOURCE="HD3">A-570-018 and C-570-019: Boltless Steel Shelving Units Prepackaged for Sale From China</HD>
                <P>
                    <E T="03">Requestor:</E>
                     Fasteners for Retail, Inc. dba Siffron. Certain headphone/speaker retail display shelves are not covered by the scope of the antidumping duty and countervailing duty orders on boltless steel shelving units prepackaged for sale from China because Siffron's display shelves are not shelving units, nor are they prepackaged for sale with upright and horizontal supports or assembled in a boltless fashion: March 29, 2024.
                </P>
                <HD SOURCE="HD3">Spain</HD>
                <HD SOURCE="HD3">A-469-823: Utility Scale Wind Towers From Spain</HD>
                <P>
                    <E T="03">Requestor:</E>
                     Orsted A/S, Orsted North America Inc. The sources enumerated in 19 CFR 351.225(k)(1) demonstrate that monopiles, 
                    <E T="03">i.e.,</E>
                     steel cylinders that serve as a foundation for offshore wind turbines, are not covered by the scope of the antidumping duty and countervailing duty orders on utility scale wind towers from Spain: February 6, 2024.
                </P>
                <HD SOURCE="HD3">Taiwan</HD>
                <HD SOURCE="HD3">A-583-869: Passenger Vehicle and Light Truck Tires From Taiwan</HD>
                <P>
                    <E T="03">Requestor:</E>
                     Cheng Shin Rubber Ind. Co. Ltd. Certain light-truck spare tires models, identified under part code TG00000100, produced by Cheng Shin Rubber Ind. Co. Ltd., and imported by its U.S. affiliate Cheng Shin Rubber USA Inc., are not covered by the scope of the antidumping duty order on passenger vehicle and light truck tires from Taiwan because the product falls under the fifth exclusion identified in the scope of the order: March 7, 2024.
                </P>
                <HD SOURCE="HD1">Notification to Interested Parties</HD>
                <P>
                    Interested parties are invited to comment on the completeness of this list of completed scope inquiries and scope/circumvention inquiry combinations made during the period January 1, 2024, through March 31, 2024. Any comments should be submitted to Scot Fullerton, Acting Deputy Assistant Secretary for AD/CVD Operations, Enforcement and Compliance, International Trade Administration, via email to 
                    <E T="03">CommerceCLU@trade.gov.</E>
                </P>
                <P>This notice is published in accordance with 19 CFR 351.225(o).</P>
                <SIG>
                    <DATED>Dated: July 30, 2024.</DATED>
                    <NAME>Scot Fullerton,</NAME>
                    <TITLE>Acting Deputy Assistant Secretary for Antidumping and Countervailing Duty Operations.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17167 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 3510-DS-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF COMMERCE</AGENCY>
                <SUBAGY>International Trade Administration</SUBAGY>
                <DEPDOC>[A-471-807]</DEPDOC>
                <SUBJECT>Certain Uncoated Paper From Portugal: Final Results of the Administrative Review of the Antidumping Duty Order; 2022-2023</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Enforcement and Compliance, International Trade Administration, U.S. Department of Commerce.</P>
                </AGY>
                <SUM>
                    <PRTPAGE P="63409"/>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The U.S. Department of Commerce (Commerce) determines that the sole producer/exporter subject to this administrative review made sales of certain uncoated paper (uncoated paper) from Portugal at less than normal value during the period of review (POR) March 1, 2022, through February 28, 2023.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Applicable August 5, 2024.</P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Eric Hawkins, AD/CVD Operations, Office V, Enforcement and Compliance, International Trade Administration, U.S. Department of Commerce, 1401 Constitution Avenue NW, Washington, DC 20230; telephone: (202) 482-1988.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">Background</HD>
                <P>
                    On April 5, 2024, Commerce published the 
                    <E T="03">Preliminary Results</E>
                     in this administrative review in the 
                    <E T="04">Federal Register</E>
                    .
                    <SU>1</SU>
                    <FTREF/>
                     Although we provided interested parties with an opportunity to comment on the 
                    <E T="03">Preliminary Results,</E>
                     no interested party submitted comments. Accordingly, the final results of review remain unchanged from the 
                    <E T="03">Preliminary Results,</E>
                     and thus, there is no decision memorandum accompanying this notice. Commerce conducted this review in accordance with section 751(a) of the Tariff Act of 1930, as amended (the Act).
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         
                        <E T="03">See Certain Uncoated Paper from Portugal: Preliminary Results of the Administrative Review of the Antidumping Duty Order; 2022-2023,</E>
                         89 FR 23975 (April 4, 2024) (
                        <E T="03">Preliminary Results</E>
                        ), and accompanying Preliminary Decision Memorandum (PDM).
                    </P>
                </FTNT>
                <HD SOURCE="HD1">
                    Scope of the Order 
                    <E T="51">2</E>
                    <FTREF/>
                </HD>
                <FTNT>
                    <P>
                        <SU>2</SU>
                         
                        <E T="03">See Certain Uncoated Paper from Australia, Brazil, Indonesia, the People's Republic of China, and Portugal: Amended Final Affirmative Antidumping Determinations for Brazil and Indonesia and Antidumping Duty Orders,</E>
                         81 FR 11174 (March 3, 2016) (
                        <E T="03">Order</E>
                        ).
                    </P>
                </FTNT>
                <P>
                    The product covered by the 
                    <E T="03">Order</E>
                     is uncoated paper from Portugal. For a complete description of the scope of the 
                    <E T="03">Order, see</E>
                     the 
                    <E T="03">Preliminary Results.</E>
                    <SU>3</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>3</SU>
                         
                        <E T="03">See Preliminary Results</E>
                         PDM at 2-3.
                    </P>
                </FTNT>
                <HD SOURCE="HD1">Final Results of the Review</HD>
                <P>For these final results, we determine that the following weighted-average dumping margin exists for the period March 1, 2022, through February 28, 2023:</P>
                <GPOTABLE COLS="2" OPTS="L2,nj,tp0,i1" CDEF="s25,9C">
                    <TTITLE> </TTITLE>
                    <BOXHD>
                        <CHED H="1">Producer and/or exporter</CHED>
                        <CHED H="1">
                            Weighted-
                            <LI>average</LI>
                            <LI>dumping</LI>
                            <LI>margin</LI>
                            <LI>(percent)</LI>
                        </CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">The Navigator Company, S.A</ENT>
                        <ENT>1.07</ENT>
                    </ROW>
                </GPOTABLE>
                <HD SOURCE="HD1">Disclosure</HD>
                <P>
                    Normally, Commerce discloses to parties to the proceeding the calculations performed in connection with a final results of review within five days of any public announcement or, if there is no public announcement, within five days of the date of publication of the notice of the final results in the 
                    <E T="04">Federal Register</E>
                    , in accordance with 19 CFR 351.224(b). However, because we made no changes from the 
                    <E T="03">Preliminary Results,</E>
                     there are no calculations to disclose.
                </P>
                <HD SOURCE="HD1">Assessment Rates</HD>
                <P>
                    Pursuant to section 751(a)(2)(C) of the Act, and 19 CFR 351.212(b)(1), Commerce has determined, and U.S. Customs and Border Protection (CBP) shall assess, antidumping duties on all appropriate entries covered by this review. Pursuant to 19 CFR 351.212(b)(1), because The Navigator Company, S.A. (Navigator) reported the entered value for all of its U.S. sales, we calculated importer-specific 
                    <E T="03">ad valorem</E>
                     duty assessment rates based on the ratio of the total amount of dumping calculated for the examined sales to the total entered value of those same sales.
                </P>
                <P>
                    Commerce's “automatic assessment” will apply to entries of subject merchandise during the POR produced by Navigator for which the company did not know that the merchandise it sold to an intermediary (
                    <E T="03">e.g.,</E>
                     a reseller, trading company, or exporter) was destined for the United States. In such instances, we will instruct CBP to liquidate such entries at the all-others rate if there is no rate for the intermediate company(ies) involved in the transaction.
                    <SU>4</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>4</SU>
                         
                        <E T="03">See Antidumping and Countervailing Duty Proceedings: Assessment of Antidumping Duties,</E>
                         68 FR 23954 (May 6, 2023).
                    </P>
                </FTNT>
                <P>
                    Commerce intends to issue assessment instructions to CBP no earlier than 35 days after the date of publication of the final results of this review in the 
                    <E T="04">Federal Register</E>
                    . If a timely summons is filed at the U.S. Court of International Trade, the assessment instructions will direct CBP not to liquidate relevant entries until the time for parties to file a request for a statutory injunction has expired (
                    <E T="03">i.e.,</E>
                     within 90 days of publication).
                </P>
                <HD SOURCE="HD1">Cash Deposit Requirements</HD>
                <P>
                    The following cash deposit requirements will be effective upon publication in the 
                    <E T="04">Federal Register</E>
                     of these final results of administrative review for all shipments of the subject merchandise entered, or withdrawn from warehouse, for consumption on or after the publication date, as provided by section 751(a)(2)(C) of the Act: (1) the cash deposit rate for Navigator will be equal to the weighted-average dumping margin established in these final results of this administrative review; (2) for merchandise exported by companies not covered in this review but covered in a prior completed segment of this proceeding, the cash deposit rate will continue to be the company-specific rate published in the completed segment for the most recent period; (3) if the exporter is not a firm covered in this review, or the less-than-fair-value (LFTV) investigation, but the producer is, then the cash deposit rate will be the cash deposit rate established for the most recently completed segment for the producer of the subject merchandise; and (4) the cash deposit rate for all other producers and exporters will continue to be the all-others rate (
                    <E T="03">i.e.,</E>
                     7.80 percent).
                    <SU>5</SU>
                    <FTREF/>
                     These cash deposit requirements, when imposed, shall remain in effect until further notice.
                </P>
                <FTNT>
                    <P>
                        <SU>5</SU>
                         
                        <E T="03">See Order.</E>
                    </P>
                </FTNT>
                <HD SOURCE="HD1">Notification to Importers</HD>
                <P>This notice serves as a final reminder to importers of their responsibility under 19 CFR 351.402(f)(2) to file a certificate regarding the reimbursement of antidumping duties prior to liquidation of the relevant entries during this review period. Failure to comply with this requirement could result in Commerce's presumption that reimbursement of antidumping duties occurred and the subsequent assessment of double antidumping duties.</P>
                <HD SOURCE="HD1">Administrative Protective Order</HD>
                <P>This notice serves as the only reminder to parties subject to an administrative protective order (APO) of their responsibility concerning the disposition of proprietary information disclosed under APO in accordance with 19 CFR 351.305(a)(3). Timely notification of the return, or destruction, of APO materials, or conversion to judicial protective order, is hereby requested. Failure to comply with the regulations and the terms of an APO is a violation subject to sanction.</P>
                <HD SOURCE="HD1">Notification to Interested Parties</HD>
                <P>This notice is being issued and published in accordance with sections 751(a)(1) and 777(i)(1) of the Act, and 19 CFR 351.221(b)(5).</P>
                <SIG>
                    <PRTPAGE P="63410"/>
                    <DATED>Dated: July 30, 2024.</DATED>
                    <NAME>Ryan Majerus,</NAME>
                    <TITLE>Deputy Assistant Secretary for Policy and Negotiations, performing the non-exclusive functions and duties of the Assistant Secretary for Enforcement and Compliance.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17250 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 3510-DS-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF COMMERCE</AGENCY>
                <SUBAGY>International Trade Administration</SUBAGY>
                <DEPDOC>[C-508-815]</DEPDOC>
                <SUBJECT>Brass Rod From Israel: Final Affirmative Countervailing Duty Determination</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Enforcement and Compliance, International Trade Administration, Department of Commerce.</P>
                </AGY>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The U.S. Department of Commerce (Commerce) determines that countervailable subsidies are being provided to producers and exporters of brass rod from Israel. The period of investigation (POI) is January 1, 2022, through December 31, 2022.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Applicable August 5, 2024.</P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Zachary Shaykin, AD/CVD Operations, Office IV, Enforcement and Compliance, International Trade Administration, U.S. Department of Commerce, 1401 Constitution Avenue NW, Washington, DC 20230; telephone: (202) 482-2638.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">Background</HD>
                <P>
                    On September 29, 2023, Commerce published its 
                    <E T="03">Preliminary Determination</E>
                    .
                    <SU>1</SU>
                    <FTREF/>
                     In the Preliminary Determination, and in accordance with section 705(a)(1) of the Tariff Act of 1930, as amended (the Act), and 19 CFR 351.210(b)(4), Commerce aligned the final countervailing duty (CVD) determination with the final antidumping duty determination.
                    <SU>2</SU>
                    <FTREF/>
                     On October 12, 2023, Commerce tolled all deadlines for this investigation for a period of 90 days due to the outbreak of war in Israel and the consequent impacts on all parts of the country.
                    <SU>3</SU>
                    <FTREF/>
                     On May 10, 2024, Commerce released its Post-Preliminary Decision.
                    <SU>4</SU>
                    <FTREF/>
                     On July 22, 2024, Commerce tolled certain deadlines in this proceeding by seven days.
                    <SU>5</SU>
                    <FTREF/>
                     The deadline for the final determination is now July 29, 2024.
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         
                        <E T="03">See Brass Rod from Israel: Preliminary Affirmative Countervailing Duty Determination, and Alignment of Final Determination With Final Antidumping Duty Determination</E>
                        , 88 FR 67236 (September 29, 2023) (
                        <E T="03">Preliminary Determination</E>
                        ).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>2</SU>
                         
                        <E T="03">Id.</E>
                        , 88 FR at 67236.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>3 </SU>
                         
                        <E T="03">See</E>
                         Memorandum, “Tolling of Deadlines in Countervailing Duty Investigation of Brass Rod from Israel,” dated October 12, 2023.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>4</SU>
                         
                        <E T="03">See</E>
                         Memorandum, “Post Preliminary Analysis,” dated May 10, 2024.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>5</SU>
                         
                        <E T="03">See</E>
                         Memorandum, “Tolling of Deadlines for Antidumping and Countervailing Duty Proceedings,” dated July 22, 2024., “Tolling of Deadlines for Antidumping and Countervailing Duty Proceedings,” dated July 22, 2024.
                    </P>
                </FTNT>
                <P>
                    For a complete description of the events that followed the 
                    <E T="03">Preliminary Determination</E>
                    , see the Issues and Decision Memorandum.
                    <SU>6</SU>
                    <FTREF/>
                     The Issues and Decision Memorandum is a public document and is made available to the public via Enforcement and Compliance's Antidumping and Countervailing Duty Centralized Electronic Service System (ACCESS). ACCESS is available to registered users at 
                    <E T="03">http://access.trade.gov.</E>
                     In addition, a complete version of the Issues and Decision Memorandum can be accessed directly at 
                    <E T="03">https://access.trade.gov/public/FRNoticesListLayout.aspx.</E>
                </P>
                <FTNT>
                    <P>
                        <SU>6</SU>
                         
                        <E T="03">See</E>
                         Memorandum, “Decision Memorandum for the Final Affirmative Determination of the Countervailing Duty Investigation of Brass Rod from Israel,” dated concurrently with, and hereby adopted by, this notice (Issues and Decision Memorandum).
                    </P>
                </FTNT>
                <HD SOURCE="HD1">Scope of the Investigation</HD>
                <P>
                    The product covered by this investigation is brass rod from Israel. For a complete description of this investigation, 
                    <E T="03">see</E>
                     Appendix I.
                </P>
                <HD SOURCE="HD1">Scope Comments</HD>
                <P>
                    During this investigation, Commerce received scope comments from parties. Commerce issued a Preliminary Scope Decision Memorandum to address these comments and set aside a period for parties to address scope issues in scope-specific case and rebuttal briefs.
                    <SU>7</SU>
                    <FTREF/>
                     We did not receive timely comments from any interested parties on the Preliminary Scope Decision Memorandum. Thus, we did not make any changes to the scope of the investigation from the scope published in the 
                    <E T="03">Preliminary Determination</E>
                     and included in Appendix I.
                    <SU>8</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>7</SU>
                         
                        <E T="03">See</E>
                         Memorandum, “Preliminary Scope Decision Memorandum,” dated September 25, 2023 (Preliminary Scope Decision Memorandum).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>8</SU>
                         
                        <E T="03">See Brass Rod from India: Final Affirmative Countervailing Duty Determination,</E>
                         88 FR 87407 (December 18, 2023); 
                        <E T="03">see also Preliminary Determination.</E>
                    </P>
                </FTNT>
                <HD SOURCE="HD1">Verification</HD>
                <P>
                    As provided in section 782(i)(1) of the Act, in May 2024, we verified the information submitted by Finkelstein and the Government of Israel (GOI) for use in our final determination. We used standard verification procedures, including an examination of relevant sales and accounting records, and original source documents provided by Finkelstein and the GOI.
                    <SU>9</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>9</SU>
                         
                        <E T="03">See</E>
                         Memorandum, “Verification of the Questionnaire Responses of the Government of Israel,” dated June 10, 2024; 
                        <E T="03">see also</E>
                         Memorandum, “Verification of the Questionnaire Responses of Finkelstein Metals Ltd.,” dated June 17, 2024.
                    </P>
                </FTNT>
                <HD SOURCE="HD1">Analysis of Subsidy Programs and Comments Received</HD>
                <P>
                    All issues raised in the case and rebuttal briefs submitted by interested parties in this investigation are addressed in the Issues and Decision Memorandum. For a list of the issues raised by interested parties and addressed in the Issues and Decision Memorandum, 
                    <E T="03">see</E>
                     Appendix II to this notice.
                </P>
                <HD SOURCE="HD1">Methodology</HD>
                <P>
                    Commerce conducted this investigation in accordance with section 701 of the Act. For each of the subsidy programs found countervailable, Commerce determines that there is a subsidy, 
                    <E T="03">i.e.,</E>
                     a financial contribution by an “authority” that gives rise to a benefit to the recipient, and that the subsidy is specific.
                    <SU>10</SU>
                    <FTREF/>
                     For a full description of the methodology underlying our final determination, 
                    <E T="03">see</E>
                     the Issues and Decision Memorandum.
                </P>
                <FTNT>
                    <P>
                        <SU>10</SU>
                         
                        <E T="03">See</E>
                         sections 771(5)(B) and (D) of the Act regarding financial contribution; section 771(5)(E) of the Act regarding benefit; and section 771(5A) of the Act regarding specificity.
                    </P>
                </FTNT>
                <HD SOURCE="HD1">Changes Since the Preliminary Determination</HD>
                <P>
                    We made certain changes to the countervailable subsidy rate calculations for Finkelstein.
                    <SU>11</SU>
                    <FTREF/>
                     For a discussion of these changes, 
                    <E T="03">see</E>
                     the Issues and Decision Memorandum.
                </P>
                <FTNT>
                    <P>
                        <SU>11</SU>
                         
                        <E T="03">See</E>
                         Memorandum, “Final Determination Calculations for Finkelstein Metals Ltd.,” dated concurrently with this notice.
                    </P>
                </FTNT>
                <HD SOURCE="HD1">All-Others Rate</HD>
                <P>
                    In accordance with section 705(c)(1)(B)(i) of the Act, we calculated an individual estimated countervailable subsidy rate for the mandatory respondent, Finkelstein. Section 705(c)(5)(A)(i) of the Act states that, for companies not individually investigated, Commerce will determine an all-others rate equal to the weighted-average countervailable subsidy rates established for exporters and/or producers individually investigated, excluding any zero and 
                    <E T="03">de minimis</E>
                     countervailable subsidy rates, and any rates determined entirely under section 776 of the Act.
                </P>
                <P>
                    We continue to calculate an individual estimated countervailable subsidy rate that is not zero, 
                    <E T="03">de minimis,</E>
                     or based entirely on facts otherwise 
                    <PRTPAGE P="63411"/>
                    available. Therefore, we have applied the all-others rate as equal to the rate for Finkelstein, 
                    <E T="03">i.e.,</E>
                     1.89 percent 
                    <E T="03">ad valorem</E>
                    , as this is the only rate that is not zero, 
                    <E T="03">de minimis,</E>
                     or based entirely on the facts otherwise available.
                </P>
                <HD SOURCE="HD1">Final Determination</HD>
                <P>Commerce determines that the following estimated countervailable subsidy rates exist:</P>
                <GPOTABLE COLS="2" OPTS="L2,tp0,i1" CDEF="s50,12">
                    <TTITLE> </TTITLE>
                    <BOXHD>
                        <CHED H="1">Company</CHED>
                        <CHED H="1">
                            Subsidy rate
                            <LI>
                                (percent 
                                <E T="03">ad valorem</E>
                                )
                            </LI>
                        </CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">Finkelstein Metals Ltd</ENT>
                        <ENT>1.89</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">All Others</ENT>
                        <ENT>1.89</ENT>
                    </ROW>
                </GPOTABLE>
                <HD SOURCE="HD1">Disclosure</HD>
                <P>Commerce intends to disclose to interested parties the calculations and analysis performed in this final determination within five days of any public announcement or, if there is no public announcement, within five days of the date of the publication of this notice in proceeding in accordance with 19 CFR 351.224(b).</P>
                <HD SOURCE="HD1">Continuation of Suspension of Liquidation</HD>
                <P>
                    As a result of our 
                    <E T="03">Preliminary Determination</E>
                    , and pursuant to sections 703(d)(1)(B) and (d)(2) of the Act, Commerce instructed U.S. Customs and Border Protection (CBP) to collect cash deposits and suspend liquidation of entries of subject merchandise as described in the scope of the investigation section entered, or withdrawn from warehouse, for consumption on September 29, 2023, the date of publication of the 
                    <E T="03">Preliminary Determination</E>
                     in the 
                    <E T="04">Federal Register</E>
                     . In accordance with section 703(d) of the Act, we issued instructions to CBP to discontinue the suspension of liquidation of subject merchandise entered, or withdrawn from warehouse, on or after January 27, 2024, but to continue the suspension of liquidation of all entries from September 29, 2023, through January 26, 2024 for Finkelstein and all producers/exporters not individually examined.
                </P>
                <P>
                    Pursuant to section 706(a)of the Act, in the event of an affirmative injury determination by the U.S. International Trade Commission (ITC), we will issue a countervailing duty order, reinstate the suspension of liquidation, and require a cash deposit of estimated countervailing duties for such entries of subject merchandise in the amounts indicated above. Effective on the date of publication in the 
                    <E T="04">Federal Register</E>
                     of the ITC's final determination, Commerce will instruct CBP to require a cash deposit equal to the estimated net countervailable subsidy rate or the estimated all others rate as follows: (1) the cash deposit rate for the companies listed above will be equal to the company-specific estimated net countervailable subsidy rate determined in this final determination; (2) if the exporter is not a respondent identified above but the producer is, then the cash deposit rate will be equal to the company-specific net countervailable subsidy rate established for that producer of the subject merchandise; and (3) the cash deposit rate for all other producers and exporters will be equal to the all-others estimated net countervailable subsidy rate.
                </P>
                <P>Pursuant to section 705(c)(2) of the Act, if the ITC determines that material injury, or threat of material injury, does not exist, this proceeding will be terminated, and all estimated duties deposited or securities posted as a result of the suspension of liquidation will be refunded or canceled.</P>
                <HD SOURCE="HD1">U.S. International Trade Commission Notification</HD>
                <P>In accordance with section 705(d) of the Act, Commerce will notify the ITC of its final affirmative determination that countervailable subsidies are being provided to producers and exporters of brass rod from Israel. Because the final determination in this proceeding is affirmative, in accordance with section 705(b) of the Act, the ITC will make its final determination as to whether the domestic industry in the United States is materially injured, or threatened with material injury, by reason of imports of brass rod from Israel no later than 45 days after our final determination. If the ITC determines that material injury or threat of material injury does not exist, this proceeding will be terminated and all cash deposits will be refunded. If the ITC determines that such injury does exist, Commerce will issue a countervailing duty order directing CBP to assess, upon further instruction by Commerce, countervailing duties on all imports of the subject merchandise that are entered, or withdrawn from warehouse, for consumption on or after the effective date of the suspension of liquidation, as discussed above in the “Continuation of Suspension of Liquidation” section. In addition, we are making available to the ITC all non-privileged and non-proprietary information in our files. We will allow the ITC access to all privileged and business proprietary information in our files, provided the ITC confirms that it will not disclose such information, either publicly or under administrative protective order (APO), without the written consent of the Assistant Secretary for Enforcement and Compliance.</P>
                <HD SOURCE="HD1">Administrative Protective Orders</HD>
                <P>This notice will serve as the only reminder to parties subject to an APO of their responsibility concerning the destruction of proprietary information disclosed under APO, in accordance with 19 CFR 351.305(a)(3). Timely written notification of the return/destruction of APO materials or conversion to judicial protective order is hereby requested. Failure to comply with the regulations and terms of an APO is a violation which is subject to sanction.</P>
                <HD SOURCE="HD1">Notification to Interested Parties</HD>
                <P>This determination and this notice are issued and published pursuant to sections 705(d) and 777(i) of the Act, and 19 CFR 351.210(c).</P>
                <SIG>
                    <DATED>Dated: July 29, 2024.</DATED>
                    <NAME>Ryan Majerus,</NAME>
                    <TITLE>Deputy Assistant Secretary for Policy and Negotiations, performing the non-exclusive functions and duties of the Assistant Secretary for Enforcement and Compliance.</TITLE>
                </SIG>
                <HD SOURCE="HD1">Appendix I</HD>
                <EXTRACT>
                    <HD SOURCE="HD1">Scope of the Investigation</HD>
                    <P>The products covered by this investigation are brass rod and bar (brass rod), which is defined as leaded, low-lead, and no-lead solid brass made from alloys such as, but not limited to the following alloys classified under the Unified Numbering System (UNS) as C27450, C27451, C27460, C34500, C35000, C35300, C35330, C36000, C36300, C37000, C37700, C48500, C67300, C67600, and C69300, and their international equivalents.</P>
                    <P>
                        The brass rod subject to this investigation has an actual cross-section or outside diameter greater than 0.25 inches but less than or equal to 12 inches. Brass rod cross-sections may be round, hexagonal, square, or octagonal shapes as well as special profiles (
                        <E T="03">e.g.,</E>
                         angles, shapes), including hollow profiles.
                    </P>
                    <P>
                        Standard leaded brass rod covered by the scope contains, by weight, 57.0—65.0 percent copper; 0.5—3.0 percent lead; no more than 1.3 percent iron; and at least 15 percent zinc. No-lead or low-lead brass rod covered by the scope contains by weight 59.0—76.0 percent copper; 0—1.5 percent lead; no more than 0.35 percent iron; and at least 15 percent zinc. Brass rod may also include other chemical elements (
                        <E T="03">e.g.,</E>
                         nickel, phosphorous, silicon, tin, etc.).
                    </P>
                    <P>
                        Brass rod may be in straight lengths or coils. Brass rod covered by this investigation may be finished or unfinished, and may or may not be heated, extruded, pickled, or cold-drawn. Brass rod may be produced in accordance with ASTM B16, ASTM B124, ASTM B981, ASTM B371, ASTM B453, ASTM B21, ASTM B138, and ASTM B927, but such conformity to an ASTM standard is not required for the merchandise to be included within the scope.
                        <PRTPAGE P="63412"/>
                    </P>
                    <P>Excluded from the scope of this investigation is brass ingot, which is a casting of unwrought metal unsuitable for conversion into brass rod without remelting, that contains, by weight, at least 57.0 percent copper and 15.0 percent zinc.</P>
                    <P>The merchandise covered by this investigation is currently classifiable under subheadings 7407.21.9000, 7407.21.7000, and 7407.21.1500 of the Harmonized Tariff Schedule of the United States (HTSUS). Products subject to the scope may also enter under HTSUS subheadings 7403.21.0000, 7407.21.3000, and 7407.21.5000. The HTSUS subheadings and UNS alloy designations are provided for convenience and customs purposes. The written description of the scope of the investigation is dispositive.</P>
                </EXTRACT>
                <HD SOURCE="HD1">Appendix II</HD>
                <EXTRACT>
                    <HD SOURCE="HD1">List of Topics Discussed in the Issues and Decision Memorandum</HD>
                    <FP SOURCE="FP-2">I. Summary</FP>
                    <FP SOURCE="FP-2">II. Background</FP>
                    <FP SOURCE="FP-2">III. Subsidies Valuation</FP>
                    <FP SOURCE="FP-2">IV. Diversification of Israel's Economy</FP>
                    <FP SOURCE="FP-2">V. Changes Since the Preliminary Determination</FP>
                    <FP SOURCE="FP-2">VI. Analysis of Programs</FP>
                    <FP SOURCE="FP-2">VII. Discussion of the Issues</FP>
                    <FP SOURCE="FP1-2">Comment 1: Whether Commerce Should Change the Benchmark Under the Land for Less-than-Adequate-Remuneration Program</FP>
                    <FP SOURCE="FP1-2">Comment 2: Whether the Provision of Natural Gas for LTAR Program Provides an Indirect Financial Contribution</FP>
                    <FP SOURCE="FP1-2">Comment 3: Whether Commerce Should Revise its Calculation of Benefits under the Provision of Brass Rod for More-Than-Adequate-Remuneration Program</FP>
                    <FP SOURCE="FP-2">VIII. Recommendation</FP>
                </EXTRACT>
            </SUPLINF>
            <FRDOC> [FR Doc. 2024-17174 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD> BILLING CODE 3510-DS-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF COMMERCE</AGENCY>
                <SUBAGY>National Institute of Standards and Technology</SUBAGY>
                <SUBJECT>National Advanced Spectrum and Communications Test Network: Citizens Broadband Radio Service Sharing Ecosystem Assessment Test Plan Community Outreach</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>National Institute of Standards and Technology, Department of Commerce.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of open meeting.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The National Advanced Spectrum and Communications Test Network (NASCTN) is hosting a public meeting on NASCTN's test plan for collecting Citizen Broadband Radio Service (CBRS) emissions in `Coastal' Dynamic Protection Areas (DPAs), on September 10, 2024, from 10 a.m.-12 p.m. mountain standard time. The purpose of this meeting is to brief Federal, industry, and academic stakeholders and interested parties from the public on the details and approach to collecting CBRS emissions for one of the two main tasks of the NASCTN CBRS Sharing Ecosystem Assessment (SEA) project.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>The NASCTN meeting on the CBRS SEA Project Always-On DPA CBRS emission collection test plan will take place September 10, 2024 from 10 a.m.-12 p.m. mountain standard time.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        The meeting will be held virtually via web conference from the NIST campus, in Boulder, CO. For instructions on how to participate in the meeting, please see the 
                        <E T="02">SUPPLEMENTARY INFORMATION</E>
                         section of this notice.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Keith Hartley at 
                        <E T="03">NASCTN@nist.gov, keith.hartley@nist.gov,</E>
                         or 719.572.8256.
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>The NASCTN CBRS SEA project seeks to provide data-driven insight into the CBRS sharing ecosystem's effectiveness between CBRS and DoD systems, and to track changes in the spectrum environment over time via two primary tasks: (1) Measure Aggregate CBRS Emissions and Noise Floor in Coastal DPAs and (2) Measure Aggregate Emissions in Always-On DPAs.</P>
                <P>NASCTN is hosting a virtual public meeting on the CBRS SEA project's Coastal DPA CBRS emission collection test plan on September 10, 2024 from 10 a.m.-12 p.m. mountain standard time. The purpose of this meeting is to brief federal, industry, and academic stakeholders and interested parties from the public on the details and approach to collecting CBRS emissions for task 1 of the two main tasks of the NASCTN CBRS SEA project.</P>
                <P>
                    Approximately 30 minutes will be allocated for public comments and questions with speaking times assigned on a first-come, first-served basis. Public comments can be provided via web conference attendance, or email. The amount of time per speaker will be determined by the number of requests received. Speakers who wish to expand upon their questions or statements, those who wish to speak but cannot be accommodated during the meeting, and those who are unable to attend are invited to submit written statements by email to 
                    <E T="03">NASCTN@nist.gov</E>
                     or 
                    <E T="03">keith.hartley@nist.gov.</E>
                     Please note that all submitted comments will be treated as public documents.
                </P>
                <P>
                    Anyone wishing to attend this meeting via web conference must register by 5 p.m. mountain standard time, August 30, 2024. Please submit your full name, email address, and phone number to Keith Hartley at 
                    <E T="03">NASCTN@nist.gov</E>
                     or 
                    <E T="03">keith.hartley@nist.gov.</E>
                </P>
                <P>
                    <E T="03">Authority:</E>
                     15 U.S.C. 278t.
                </P>
                <SIG>
                    <NAME>Alicia Chambers,</NAME>
                    <TITLE>NIST Executive Secretariat.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17207 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 3510-13-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF COMMERCE</AGENCY>
                <SUBAGY>National Oceanic and Atmospheric Administration</SUBAGY>
                <DEPDOC>[RTID 0648-XE164]</DEPDOC>
                <SUBJECT>Endangered Species; File No. 28148</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>National Marine Fisheries Service (NMFS), National Oceanic and Atmospheric Administration (NOAA), Commerce.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice; receipt of application.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>
                        Notice is hereby given that NMFS Pacific Islands Regional Office, 1845 Wasp Boulevard, Building 176, Honolulu, HI 96818 (Jamie Marchetti, Responsible Party), has applied in due form for a permit to take green (
                        <E T="03">Chelonia mydas</E>
                        ), hawksbill (
                        <E T="03">Eretmochelys imbricata</E>
                        ), leatherback (
                        <E T="03">Dermochelys coriacea</E>
                        ), loggerhead (
                        <E T="03">Caretta caretta</E>
                        ), and olive ridley (
                        <E T="03">Lepidochelys olivacea</E>
                        ) sea turtles for purposes of scientific research.
                    </P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Written comments must be received on or before September 4, 2024.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        The application and related documents are available for review by selecting “Records Open for Public Comment” from the “Features” box on the Applications and Permits for Protected Species home page, 
                        <E T="03">https://apps.nmfs.noaa.gov,</E>
                         and then selecting File No. 28148 from the list of available applications. These documents are also available upon written request via email to 
                        <E T="03">NMFS.Pr1Comments@noaa.gov.</E>
                    </P>
                    <P>
                        Written comments on this application should be submitted via email to 
                        <E T="03">NMFS.Pr1Comments@noaa.gov.</E>
                         Please include File No. 28148 in the subject line of the email comment.
                    </P>
                    <P>
                        Those individuals requesting a public hearing should submit a written request via email to 
                        <E T="03">NMFS.Pr1Comments@noaa.gov.</E>
                         The request should set forth the specific reasons why a hearing on this application would be appropriate.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Erin Markin, Ph.D., or Malcolm Mohead, (301) 427-8401.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    The subject permit is requested under the authority of the Endangered Species Act of 1973, as amended (ESA; 16 U.S.C. 
                    <PRTPAGE P="63413"/>
                    1531 
                    <E T="03">et seq.</E>
                    ) and the regulations governing the taking, importing, and exporting of endangered and threatened species (50 CFR parts 222-226).
                </P>
                <P>The applicant proposes to assess post-hooking survival, movements, and ecology, provide critical life history information, and genetic information to aid in the development of methods to reduce sea turtles interactions with fishing gear. The applicant proposes to conduct research on sea turtles bycaught in three longline Pacific fisheries (Hawaii Deep-Set Longline Fishery, Hawaii Shallow-Set Longline Fishery, and American Samoa Longline Fishery). Turtles may be flipper tagged, skin biopsied, satellite tagged (epoxy attachment), measured, and photographed/videoed prior to release. Biological samples may be imported from the high seas. The applicant may conduct research on the number of turtles authorized to be incidentally taken in each fishery. The permit would be valid for 5 years from the date of issuance.</P>
                <SIG>
                    <DATED>Dated: July 30, 2024.</DATED>
                    <NAME>Julia M. Harrison,</NAME>
                    <TITLE>Chief, Permits and Conservation Division, Office of Protected Resources, National Marine Fisheries Service.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17225 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 3510-22-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF COMMERCE</AGENCY>
                <SUBAGY>National Oceanic and Atmospheric Administration</SUBAGY>
                <DEPDOC>[RTID 0648-XE158]</DEPDOC>
                <SUBJECT>Mid-Atlantic Fishery Management Council (MAFMC); Public Meeting</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>National Marine Fisheries Service (NMFS), National Oceanic and Atmospheric Administration (NOAA), Commerce.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice; public meeting.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Mid-Atlantic Fishery Management Council will hold a public webinar to collect input to inform development of the Council's next strategic plan for 2025-2029.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>
                        The meeting will be held on Tuesday, August 20, 2024, from 2 p.m. until 3:30 p.m. See 
                        <E T="02">SUPPLEMENTARY INFORMATION</E>
                         for details.
                    </P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        The meeting will be held via webinar. Connection information will be posted prior to the meeting at 
                        <E T="03">www.mafmc.org.</E>
                    </P>
                    <P>
                        <E T="03">Council address:</E>
                         Mid-Atlantic Fishery Management Council, 800 N State Street, Suite 201, Dover, DE 19901; telephone: (302) 674-2331; 
                        <E T="03">www.mafmc.org.</E>
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Christopher M. Moore, Ph.D., Executive Director, Mid-Atlantic Fishery Management Council, telephone: (302) 526-5255.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>The Mid-Atlantic Fishery Management Council is guided by a five-year strategic plan. The plan serves as a roadmap that is used to prioritize fishery management actions, focus resources, and ensure steady progress toward long-term goals. The current strategic plan will expire at the end of 2024, and the Council is in the process of developing the next strategic plan for 2025-2029.</P>
                <P>
                    During the webinar, the public will have an opportunity to provide feedback on the Council's performance relative to the 2020-2024 strategic plan and provide recommendations for priority issues to be addressed in the 2025-2029 plan. Additional information, updates, and instructions for providing written comments will be posted to the Council's website at: 
                    <E T="03">https://www.mafmc.org/strategic-plan.</E>
                </P>
                <HD SOURCE="HD1">Special Accommodations</HD>
                <P>The meeting is physically accessible to people with disabilities. Requests for sign language interpretation or other auxiliary aids should be directed to Shelley Spedden, (302) 526-5251 at least 5 days prior to the meeting date.</P>
                <P>
                    <E T="03">Authority:</E>
                     16 U.S.C. 1801 
                    <E T="03">et seq.</E>
                </P>
                <SIG>
                    <DATED>Dated: July 31, 2024.</DATED>
                    <NAME>Rey Israel Marquez,</NAME>
                    <TITLE>Acting Deputy Director, Office of Sustainable Fisheries, National Marine Fisheries Service.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17230 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 3510-22-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF COMMERCE</AGENCY>
                <SUBAGY>National Oceanic and Atmospheric Administration</SUBAGY>
                <SUBJECT>Ocean Research Advisory Panel (ORAP)</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>National Oceanic and Atmospheric Administration (NOAA), Department of Commerce (DOC).</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of public meeting.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>This notice sets forth the schedule and proposed agenda of a meeting of the Ocean Research Advisory Panel (ORAP). The members will discuss issues outlined in the section on Matters to be Considered.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>The meeting is scheduled for September 4, 2024 from 9 a.m. to 5 p.m. Hawaii standard time (HST) and September 5, 2024 from 8:30 a.m. to 12:30 p.m. HST. These times and the agenda topics described below are subject to change.</P>
                    <P>
                        For the latest agenda please refer to the ORAP website: 
                        <E T="03">https://www.noaa.gov/ocean-research-advisory-panel/orap-public-meetings.</E>
                    </P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        The September 4-5, 2024 meeting will be at the Hawai'i Imin International Conference Center, 1777 East-West Road, Honolulu, Hawai'i 96848. The link for the webinar registration will be posted, when available, on the ORAP website: 
                        <E T="03">https://www.noaa.gov/ocean-research-advisory-panel/orap-public-meetings.</E>
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Viviane Silva, ORAP Designated Federal Officer (DFO), SSMC3, Room 11320, 1315 East-West Hwy., Silver Spring, MD 20910; Phone Number: 240-624-0656; Email: 
                        <E T="03">DFO.orap@noaa.gov;</E>
                         or visit the ORAP website at 
                        <E T="03">https://www.noaa.gov/ocean-research-advisory-panel/orap-public-meetings.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>The Ocean Research Advisory Panel (ORAP) advises the Ocean Policy Committee (OPC) and provides independent recommendations to the Federal Government on matters of ocean policy.</P>
                <P>Congress directed the establishment of the ORAP in section 1055(c) of the William M. (Mac) Thornberry National Defense Authorization Act for Fiscal Year 2021 (Pub. L. 116-283), 10 U.S.C. 8933.</P>
                <P>ORAP's responsibilities are (1) to advise the OPC on policies and procedures to implement the National Oceanographic Partnership Program; (2) to advise the OPC on matters relating to national oceanographic science, engineering, facilities, or resource requirements; (3) to advise the OPC on improving diversity, equity, and inclusion in the ocean sciences and related fields; (4) to advise the OPC on national ocean research priorities; and (5) any additional responsibilities that the OPC considers appropriate.</P>
                <P>
                    <E T="03">Status:</E>
                     The September 4-5, 2024 meeting will be open to public participation with a 30-minute public comment period at 3:15 p.m. HST on September 4th. The ORAP expects that public statements presented at its meetings will not be repetitive of previously submitted verbal or written statements. In general, each individual or group making a verbal presentation will be limited to a total time of three-five minutes. Written comments for the September 4-5, 2024 meeting should be received by August 19, 2024 by the ORAP DFO (
                    <E T="03">DFO.orap@noaa.gov</E>
                    ) to provide sufficient time for ORAP review. Written comments received by the ORAP DFO after this date will be 
                    <PRTPAGE P="63414"/>
                    distributed to the ORAP, but may not be reviewed prior to the meeting date.
                </P>
                <P>
                    <E T="03">Special Accommodations:</E>
                     These meetings are physically accessible to people with disabilities. Requests for special accommodations may be directed to the ORAP DFO no later than 12 p.m. EDT on August 19, 2024.
                </P>
                <P>
                    <E T="03">Matters to be Considered:</E>
                     During the ORAP meeting on Dec. 13-14, 2023, the Ocean Policy Committee (OPC) requested that the ORAP advise on areas of opportunity for partnership (such as through the National Oceanic Partnership Program) on the topic of emerging technology (which could include Artificial Intelligence/Machine Learning, eDNA, and similar technology) with ocean industry and other sectors over the next 5-10 years. The OPC also requested that ORAP self-select another topic to address. The ORAP members agreed that the topic of accessible, inter-operable, interdisciplinary, and trusted ocean data to meet research and user needs is critical and deserves ORAP immediate attention. At this meeting on September 4-5, 2024, ORAP members will hear from the ORAP subgroups on the two OPC tasks progress and hear from Native Hawaiian and Pacific Islander communities on Indigenous perspectives, knowledge, and practices related to the Ocean, in particular, insights on emerging technology and data.
                </P>
                <P>
                    Meeting materials, including work products, will be made available on the ORAP website: 
                    <E T="03">https://www.noaa.gov/ocean-research-advisory-panel/orap-public-meetings.</E>
                </P>
                <SIG>
                    <DATED>Dated: July 16, 2024.</DATED>
                    <NAME>David Holst,</NAME>
                    <TITLE>Director Chief Financial Officer/CAO, Office of Oceanic and Atmospheric Research, National Oceanic and Atmospheric Administration.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17226 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 3510-KD-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF COMMERCE</AGENCY>
                <SUBAGY>National Oceanic and Atmospheric Administration</SUBAGY>
                <DEPDOC>[RTID 0648-XE159]</DEPDOC>
                <SUBJECT>New England Fishery Management Council; Public Meeting</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>National Marine Fisheries Service (NMFS), National Oceanic and Atmospheric Administration (NOAA), Commerce.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of a public meeting.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The New England Fishery Management Council (Council) is scheduling a public meeting of its Joint Herring Committee and Advisory Panel via webinar to consider actions affecting New England fisheries in the exclusive economic zone (EEZ). Recommendations from this group will be brought to the full Council for formal consideration and action, if appropriate.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>This webinar will be held on Thursday, August 22, 2024, at 1 p.m.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P/>
                    <P>
                        <E T="03">Webinar registration URL information: https://nefmc-org.zoom.us/meeting/register/tJUlde2hqj0rE9S93wF9at0Dq8m3tUI-2n9d.</E>
                    </P>
                    <P>
                        <E T="03">Council address:</E>
                         New England Fishery Management Council, 50 Water Street, Mill 2, Newburyport, MA 01950.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Cate O'Keefe, Executive Director, New England Fishery Management Council; telephone: (978) 465-0492.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">Agenda</HD>
                <P>The Atlantic Herring Committee and Advisory Panel will meet to discuss the following items: Atlantic Herring Specifications for 2025-2027: Receive an update on the development of this action, including: (1) a report from the Plan Development Team and ASMFC's Technical Committee, (2) an overview of the 2024 management track stock assessment, (3) a summary of the Scientific and Statistical Committee's recommendations, and (4) a summary of the ASMFC Atlantic Herring Board's discussions. In response to the results of the 2024 management track stock assessment and to meet conservation and management objectives for Atlantic herring, engage in Committee discussion on whether to recommend additional management measures, including the possibility of initiating a framework adjustment or considering in-season adjustments for 2024 and 2025 catch limits, along with any other recommendations as appropriate. Other business will be discussed, if necessary.</P>
                <P>Although non-emergency issues not contained on the agenda may come before this Council for discussion, those issues may not be the subject of formal action during this meeting. Council action will be restricted to those issues specifically listed in this notice and any issues arising after publication of this notice that require emergency action under section 305(c) of the Magnuson-Stevens Act, provided the public has been notified of the Council's intent to take final action to address the emergency. The public also should be aware that the meeting will be recorded. Consistent with 16 U.S.C. 1852, a copy of the recording is available upon request.</P>
                <HD SOURCE="HD1">Special Accommodations</HD>
                <P>This meeting is physically accessible to people with disabilities. Requests for sign language interpretation or other auxiliary aids should be directed to Cate O'Keefe, Executive Director, at (978) 465-0492, at least 5 days prior to the meeting date.</P>
                <P>
                    <E T="03">Authority:</E>
                     16 U.S.C. 1801 
                    <E T="03">et seq.</E>
                </P>
                <SIG>
                    <DATED>Dated: July 31, 2024.</DATED>
                    <NAME>Rey Israel Marquez,</NAME>
                    <TITLE>Acting Deputy Director, Office of Sustainable Fisheries, National Marine Fisheries Service.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17231 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 3510-22-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF COMMERCE</AGENCY>
                <SUBAGY>National Oceanic and Atmospheric Administration</SUBAGY>
                <DEPDOC>[RTID 0648-XE147]</DEPDOC>
                <SUBJECT>Endangered Species; File No. 27686</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>National Marine Fisheries Service (NMFS), National Oceanic and Atmospheric Administration (NOAA), Commerce.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice; issuance of permit.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>
                        Notice is hereby given that Hudson River Sloop Clearwater, Inc., (Clearwater) has been issued a permit for the incidental take of shortnose (
                        <E T="03">Acipenser brevirostrum</E>
                        ) and Atlantic sturgeon (
                        <E T="03">A. oxyrinchus</E>
                        ) associated with the otherwise lawful education trawl in the Hudson River.
                    </P>
                </SUM>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        The permit and related documents are available on the NMFS Office of Protected Resources website at: 
                        <E T="03">https://www.fisheries.noaa.gov/action/incidental-take-permit-hudson-river-sloop-clearwater-inc.</E>
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Steven Hughes, (301) 427-8576, 
                        <E T="03">steven.hughes@noaa.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    Section 9 of the Endangered Species Act (ESA) and Federal regulations prohibits the “taking” of a species listed as endangered or threatened. The ESA defines “take” to mean harass, harm, pursue, hunt, shoot, wound, kill, trap, capture, or collect, or to attempt to engage in any such conduct. NMFS may issue permits, under limited circumstances, to take listed species when the takes are incidental to, and not the purpose of, otherwise lawful activities. Section 10(a)(1)(B) of the ESA provides for authorizing incidental take of listed species. The regulations for issuing incidental take permits for 
                    <PRTPAGE P="63415"/>
                    threatened and endangered species are promulgated at 50 CFR 222.307.
                </P>
                <HD SOURCE="HD1">Species Covered in This Notice</HD>
                <P>
                    The following species are included in the conservation plan and permit application: Atlantic (
                    <E T="03">Acipenser oxyrinchus</E>
                    ) and shortnose (
                    <E T="03">A. brevirostrum</E>
                    ) sturgeon.
                </P>
                <HD SOURCE="HD1">Background</HD>
                <P>
                    On September 29, 2023, notice was published in the 
                    <E T="04">Federal Register</E>
                     (88 FR 67249) that a request for a permit for the incidental take of shortnose and Atlantic sturgeon associated with the otherwise lawful education trawl in the Hudson River by Clearwater, Inc. No comments were received during the 30 day public comment period. The requested permit has been issued under the authority of the ESA of 1973, as amended (16 U.S.C. 1531 
                    <E T="03">et seq.</E>
                    ) and the regulations governing the taking, importing, and exporting of endangered and threatened species (50 CFR parts 222-226).
                </P>
                <HD SOURCE="HD1">Permit No. 27686</HD>
                <P>The permit authorizes take of ESA-listed shortnose and Atlantic sturgeon that are caught incidental to educational trawls in the Hudson River. Clearwater will not exceed take of 10 sturgeon, with 1 or more a year (combination of shortnose and Atlantic Sturgeon) over the 10 year permit. There will be one lethal take permitted over the 10 year permit.</P>
                <HD SOURCE="HD1">Conservation Plan</HD>
                <P>
                    Section 10 of the ESA specifies that no permit may be issued unless an applicant submits an adequate conservation plan. The conservation plan prepared by Clearwater describes measures designed to minimize and mitigate the impacts of any incidental take of ESA-listed shortnose sturgeon and Atlantic sturgeon. Clearwater will regularly communicate with New York State Department of Environmental Conservation to avoid known sturgeon habitat and spawning grounds. Clearwater will avoid trawling the river at Poughkeepsie and Norrie Point due to known sensitive habitat. Clearwater will use small otter trawls (38.1 × 76.2 centimeter) doors weighing 50 pounds and short tow times (≤5 minutes). Beach seines, which allow for targeted catch, will be used where practicable (
                    <E T="03">e.g.,</E>
                     away from urban areas and where tides allow). If Clearwater incidentally captures a sturgeon in its nets, it will follow protocols for safe handling and immediately release any sturgeon caught. Clearwater will maintain a detailed log of all gear sets and will submit to NMFS incidental and annual reports of incidental capture, if any, of listed sturgeon.
                </P>
                <HD SOURCE="HD1">National Environmental Policy Act</HD>
                <P>
                    Issuing an ESA section 10(a)(1)(B) permit constitutes a Federal action requiring NMFS to comply with the National Environmental Policy Act (42 U.S.C. 4321 
                    <E T="03">et seq.</E>
                    ) as implemented by 40 CFR parts 1500-1508 and NOAA Administrative Order 216-6, Environmental Review Procedures for Implementing the National Policy Act (1999). NMFS has determined that the activity proposed is categorically excluded from the requirement to prepare an environmental assessment or environmental impact statement. This action falls within the B3 category: issuance of, and amendments to, “low effect” Incidental Take Permits and their supporting “low effect” Habitat Conservation Plans under section 10(a)(1)(B) of the ESA. Additionally there are no extraordinary circumstances with the potential for significant environmental effects that would preclude the issuance of this permit type from being categorically excluded.
                </P>
                <SIG>
                    <DATED>Dated: July 25, 2024.</DATED>
                    <NAME>Angela Somma,</NAME>
                    <TITLE>Chief, Endangered Species Division, Office of Protected Resources, National Marine Fisheries Service.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17252 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 3510-22-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">COMMITTEE FOR THE IMPLEMENTATION OF TEXTILE AGREEMENTS</AGENCY>
                <SUBJECT>Determination Under the Textile and Apparel Commercial Availability Provision of the Dominican Republic-Central America-United States Free Trade Agreement (“CAFTA-DR”)</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>The Committee for the Implementation of Textile Agreements.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Determination to add a product in unrestricted quantities to Annex 3.25 of the CAFTA-DR.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Committee for the Implementation of Textile Agreements (“CITA”) has determined that certain nylon/polyester dobby weave fabric, as specified below, is not available in commercial quantities in a timely manner in the CAFTA-DR countries. The product is added to the list in Annex 3.25 of the CAFTA-DR in unrestricted quantities.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>
                        <E T="03">Applicable Date:</E>
                         August 5, 2024.
                    </P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Kayla Johnson, Office of Textiles and Apparel, U.S. Department of Commerce, (202) 482-2532 or 
                        <E T="03">kayla.johnson@trade.gov.</E>
                    </P>
                    <P>
                        <E T="03">For Further Information Online: https://otexaprod.trade.gov/otexacapublicsite/requests/cafta</E>
                         under “Approved Requests,” File Number: CA2024002.
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P/>
                <P>
                    <E T="03">Authority:</E>
                     The CAFTA-DR; Section 203(o)(4) of the Dominican Republic-Central America-United States Free Trade Agreement Implementation Act (“CAFTA-DR Implementation Act”), Public Law 109-53; the Statement of Administrative Action accompanying the CAFTA-DR Implementation Act; and Presidential Proclamation 7987 (February 28, 2006).
                </P>
                <P>
                    <E T="03">Background:</E>
                     The CAFTA-DR provides a list in Annex 3.25 for fabrics, yarns, and fibers that the Parties to the CAFTA-DR have determined are not available in commercial quantities in a timely manner in the territory of any Party. The CAFTA-DR provides that this list may be modified pursuant to Article 3.25.4, when the United States determines that a fabric, yarn, or fiber is not available in commercial quantities in a timely manner in the territory of any Party. 
                    <E T="03">See</E>
                     Annex 3.25 of the CAFTA-DR; 
                    <E T="03">see also</E>
                     section 203(o)(4)(C) of the CAFTA-DR Implementation Act.
                </P>
                <P>
                    The CAFTA-DR Implementation Act requires the President to establish procedures governing the submission of a request and providing opportunity for interested entities to submit comments and supporting evidence before a commercial availability determination is made. In Presidential Proclamation 7987, the President delegated to CITA the authority under section 203(o)(4) of CAFTA-DR Implementation Act for modifying the Annex 3.25 list. Pursuant to this authority, on September 15, 2008, CITA published modified procedures it would follow in considering requests to modify the Annex 3.25 list of products determined to be not commercially available in the territory of any Party to the CAFTA-DR (
                    <E T="03">Modifications to Procedures for Considering Requests Under the Commercial Availability Provision of the Dominican Republic-Central America-United States Free Trade Agreement,</E>
                     73 FR 53200) (“CITA's Procedures”).
                </P>
                <P>
                    On June 21, 2024, CITA received a Commercial Availability Request (“Request”) from Barnes &amp; Thornburg LLP on behalf of The Powers Manufacturing Company d/b/a Powers Athletic (“Powers Athletic”) for certain nylon/polyester dobby weave fabric, as 
                    <PRTPAGE P="63416"/>
                    specified below. On June 25, 2024, in accordance with CITA's Procedures, CITA notified interested parties of the Request, which was posted on the dedicated website for CAFTA-DR Commercial Availability proceedings. In its notification, CITA advised that any Response with an Offer to Supply (“Response”) must be submitted by July 8, 2024, and any Rebuttal to a Response (“Rebuttal”) must be submitted by July 12, 2024, in accordance with sections 6 and 7 of CITA's Procedures. No interested entity submitted a Response to the Request advising CITA of its objection to the Request with an offer to supply the subject product in accordance with CITA's Procedures.
                </P>
                <P>In accordance with section 203(o)(4)(C) of the CAFTA-DR Implementation Act, and section 8(c)(2) of CITA's Procedures, as no interested entity submitted a Response objecting to the Request and providing an offer to supply the subject product in accordance with CITA's Procedures, CITA has determined to add the specified fabric to the list in Annex 3.25 of the CAFTA-DR.</P>
                <P>
                    The subject product has been added to the list in Annex 3.25 of the CAFTA-DR Agreement in unrestricted quantities. A revised list has been posted on the dedicated website for CAFTA-DR Commercial Availability proceedings, at 
                    <E T="03">https://otexaprod.trade.gov/otexacapublicsite/shortsupply/cafta.</E>
                </P>
                <HD SOURCE="HD1">Specifications: Certain Nylon/Polyester Dobby Weave Fabric</HD>
                <FP SOURCE="FP-2">
                    <E T="03">HTS:</E>
                     5407.73.2015, 5407.73.2060, 5407.53.2020, and 5407.53.2060
                </FP>
                <FP SOURCE="FP-2">
                    <E T="03">Fabric Type:</E>
                     Dobby Weave on a Triple Beam Air Jet Loom
                </FP>
                <FP SOURCE="FP-2">
                    <E T="03">Fabric Content:</E>
                     78%-88% Polyester/12%-22% Nylon
                </FP>
                <FP SOURCE="FP-2">
                    <E T="03">Yarn Size:</E>
                </FP>
                <FP SOURCE="FP1-2">
                    <E T="03">Warp Yarn 1:</E>
                     Polyester 170Denier/144Filament Full Dull Air Textured Yarn (FDATY)
                </FP>
                <FP SOURCE="FP1-2">
                    <E T="03">Warp Yarn 2:</E>
                     166D/68F Nylon
                </FP>
                <FP SOURCE="FP1-2">
                    <E T="03">Warp Yarn 3:</E>
                     Nylon 30D monofilament
                </FP>
                <FP SOURCE="FP1-2">
                    <E T="03">Filling Yarn 1:</E>
                     Polyester 75D/72F Semi Dull Texturized
                </FP>
                <FP SOURCE="FP1-2">
                    <E T="03">Filling Yarn 2:</E>
                     Polyester 170D/144F
                </FP>
                <FP SOURCE="FP1-2">
                    <E T="03">Filling Yarn 3:</E>
                     Nylon 30D monofilament + 166D/68F Cordura (Nylon 6.6)
                </FP>
                <NOTE>
                    <HD SOURCE="HED">Note: </HD>
                    <P>Yarn size may vary by +/− 5% after processing. The yarn size designations describe a range of specifications for yarn in its greige condition. They are intended as specifications to be followed by the mill in sourcing yarn to produce the fabric. Weaving, dyeing, and finishing can alter the characteristic of the yarn as it appears in the finished fabric. This specification therefore includes yarns appearing in the finished fabric as finer or coarser than the designated yarn sizes, provided that the variation occurs after processing of the greige yarn and production of the fabric.</P>
                </NOTE>
                <FP SOURCE="FP-2">
                    <E T="03">Thread Count:</E>
                </FP>
                <FP SOURCE="FP1-2">
                    <E T="03">Metric:</E>
                     Various
                </FP>
                <FP SOURCE="FP1-2">
                    <E T="03">English:</E>
                     Various
                </FP>
                <FP SOURCE="FP-2">
                    <E T="03">Weight:</E>
                     147-185 grams per sq. meter
                </FP>
                <FP SOURCE="FP-2">
                    <E T="03">Finished Density (ends/cm x picks/cm):</E>
                     102-113 x 159-176
                </FP>
                <FP SOURCE="FP-2">
                    <E T="03">Face Side (Technical Face or Back):</E>
                     Technical Side
                </FP>
                <FP SOURCE="FP-2">
                    <E T="03">Width:</E>
                </FP>
                <FP SOURCE="FP1-2">
                    <E T="03">Metric:</E>
                     137 to 150 cm, 142.24 cuttable
                </FP>
                <FP SOURCE="FP1-2">
                    <E T="03">English:</E>
                     54-60 inches, 57 cuttable
                </FP>
                <FP SOURCE="FP-2">
                    <E T="03">Dye Type:</E>
                     Yarn Dye of Various colors
                </FP>
                <SIG>
                    <NAME>Megan Crowe,</NAME>
                    <TITLE>Acting Chairman, Committee for the Implementation of Textile Agreements.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17233 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 3510-DR-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">CONSUMER PRODUCT SAFETY COMMISSION</AGENCY>
                <SUBJECT>Sunshine Act Meeting</SUBJECT>
                <PREAMHD>
                    <HD SOURCE="HED">TIME AND DATE: </HD>
                    <P>Wednesday, August 7, 2024—10 a.m.</P>
                </PREAMHD>
                <PREAMHD>
                    <HD SOURCE="HED">PLACE: </HD>
                    <P>The meeting will be held remotely, and in person at 4330 East West Highway, Bethesda, Maryland 20814.</P>
                </PREAMHD>
                <PREAMHD>
                    <HD SOURCE="HED">STATUS: </HD>
                    <P>Commission Meeting—Open to the Public.</P>
                </PREAMHD>
                <PREAMHD>
                    <HD SOURCE="HED">MATTER TO BE CONSIDERED:</HD>
                    <P>
                          
                        <E T="03">Briefing Matter:</E>
                         Notice of Proposed Rulemaking: Requirements for Water Beads.
                    </P>
                    <P>
                        To attend remotely, please use the following link: 
                        <E T="03">https://cpsc.webex.com/cpsc/j.php?MTID=m232a0e248a240baa174dbbfe0a40e831.</E>
                    </P>
                </PREAMHD>
                <PREAMHD>
                    <HD SOURCE="HED">CONTACT PERSON FOR MORE INFORMATION: </HD>
                    <P>Alberta E. Mills, Office of the Secretary, U.S. Consumer Product Safety Commission, 4330 East West Highway, Bethesda, MD 20814, 301-504-7479 (Office) or 240-863-8938 (Cell).</P>
                </PREAMHD>
                <SIG>
                    <DATED>Dated: July 31, 2024.</DATED>
                    <NAME>Alberta E. Mills,</NAME>
                    <TITLE>Commission Secretary.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2024-17297 Filed 8-1-24; 11:15 am]</FRDOC>
            <BILCOD>BILLING CODE 6355-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">DEPARTMENT OF DEFENSE</AGENCY>
                <SUBAGY>Department of the Air Force</SUBAGY>
                <DEPDOC>[Docket ID: USAF-2024-HQ-0006]</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 October 4, 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 05F16, 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 the Airman and Family Readiness Operations Division (AFPC/DPFF), Directorate of Airman &amp; Family Care; 550 C. Street West, JBSA-Randolph AFB, TX 78150, ATTN: Mr. Patrick Woodworth, or call 210-565-3280.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P/>
                <P>
                    <E T="03">Title; Associated Form; and OMB Number:</E>
                     Air Force Family Integrated Results &amp; Statistical Tracking 
                    <PRTPAGE P="63417"/>
                    Automated System; OMB Control Number 0701-0070.
                </P>
                <P>
                    <E T="03">Needs and Uses:</E>
                     The information collection requirement is necessary to record demographic information on Airman &amp; Family Readiness Center (A&amp;FRC) customers, results of the customer's visits, determine customer needs, service plan, referrals, workshop attendance and other related A&amp;FRC activities and services accessed by the customer. Data is used to determine the effectiveness of A&amp;FRC activities and services (results management) as well as collect and provide return on investment data to leadership. Information is compiled for statistical reporting to military bases, major commands, Headquarters United States Air Force, DoD and Congress.
                </P>
                <P>
                    <E T="03">Affected Public:</E>
                     Individuals or households.
                </P>
                <P>
                    <E T="03">Annual Burden Hours:</E>
                     9,375.
                </P>
                <P>
                    <E T="03">Number of Respondents:</E>
                     37,500.
                </P>
                <P>
                    <E T="03">Responses per Respondent:</E>
                     1.
                </P>
                <P>
                    <E T="03">Annual Responses:</E>
                     37,500.
                </P>
                <P>
                    <E T="03">Average Burden per Response:</E>
                     15 minutes.
                </P>
                <P>
                    <E T="03">Frequency:</E>
                     On occasion.
                </P>
                <SIG>
                    <DATED>Dated: July 30, 2024.</DATED>
                    <NAME>Aaron T. Siegel,</NAME>
                    <TITLE>Alternate OSD Federal Register Liaison Officer, Department of Defense.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17175 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6001-FR-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF DEFENSE</AGENCY>
                <SUBAGY>Department of the Army</SUBAGY>
                <DEPDOC>[Docket ID: USA-2024-HQ-0010]</DEPDOC>
                <SUBJECT>Proposed Collection; Comment Request</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Department of the Army, 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 Army &amp; Air Force Exchange Service (Exchange) 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 October 4, 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 05F16, 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 Army &amp; Air Force Exchange Service, Office of the General Counsel, Compliance Division, ATTN: Teresa Schreurs, 3911 South Walton Walker Blvd., Dallas, TX 75236-1598, through email to 
                        <E T="03">PrivacyManager@aafes.com,</E>
                         or call the Exchange Compliance Division at 800-967-6067, Option 5.
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P/>
                <P>
                    <E T="03">Title; Associated Form; and OMB Number:</E>
                     Exchange Official Personnel Folder—Privilege Card; Exchange Form 1100-016; OMB Control Number 0702-0129.
                </P>
                <P>
                    <E T="03">Needs and Uses:</E>
                     The information collection requirement is necessary to obtain authorization or continued authorization for patronage to exchange associate dependents for shopping privileges. Respondents are Exchange employee dependents who wish to become or remain eligible Exchange patrons. Exchange Form 1100-016 provides Exchange Human Resources information to verify and authorize patronage to these individuals. If approved, the individual will obtain a personalized, laminated dependent card for shopping privileges.
                </P>
                <P>
                    <E T="03">Affected Public:</E>
                     Individuals or households.
                </P>
                <P>
                    <E T="03">Annual Burden Hours:</E>
                     52.
                </P>
                <P>
                    <E T="03">Number of Respondents:</E>
                     207.
                </P>
                <P>
                    <E T="03">Responses per Respondent:</E>
                     1.
                </P>
                <P>
                    <E T="03">Annual Responses:</E>
                     207.
                </P>
                <P>
                    <E T="03">Average Burden per Response:</E>
                     15 minutes.
                </P>
                <P>
                    <E T="03">Frequency:</E>
                     On occasion.
                </P>
                <SIG>
                    <DATED>Dated: July 30, 2024.</DATED>
                    <NAME>Aaron T. Siegel,</NAME>
                    <TITLE>Alternate OSD Federal Register Liaison Officer, Department of Defense.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17163 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6001-FR-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF DEFENSE</AGENCY>
                <SUBAGY>Department of the Army</SUBAGY>
                <DEPDOC>[Docket ID: USA-2024-HQ-0011]</DEPDOC>
                <SUBJECT>Proposed Collection; Comment Request</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Department of the Army, 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 Army &amp; Air Force Exchange Service (Exchange) 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 October 4, 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 05F16, 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 
                        <PRTPAGE P="63418"/>
                        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 Army &amp; Air Force Exchange Service, Office of the General Counsel, Compliance Division, ATTN: Teresa Schreurs, 3911 South Walton Walker Blvd., Dallas, TX 75236-1598 through email to 
                        <E T="03">PrivacyManager@aafes.com,</E>
                         or call the Exchange Compliance Division at 800-967-6067, Option 5.
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P/>
                <P>
                    <E T="03">Title; Associated Form; and OMB Number:</E>
                     Exchange Customer Satisfaction Surveys; OMB Control Number 0702-0130.
                </P>
                <P>
                    <E T="03">Needs and Uses:</E>
                     The information collection requirement is necessary to provide the Exchange with holistic views of customers' shopping experiences. These surveys aid the Exchange's marketing directorate to address the effectiveness of providing goods and services and the quality of the Exchange mobile app and online shopping functionality, design, and use to meet with the patron's wants and desires. Respondents are authorized customers of the Army and Air Force Exchange Service, who voluntarily provide opinions or comments regarding their recent shopping experience at an Exchange facility or use of the Exchange on-line or mobile app. The survey provides valuable data used to enhance the customer's experience. If the Exchange does not receive data through these surveys, the Exchange's efforts to improve the customer shopping experience would not be as effective, efficient, or useful. Customer information is vital to the efficient and effective maintenance and improvement of the Exchange operations. The survey does not collect PII data.
                </P>
                <P>
                    <E T="03">Affected Public:</E>
                     Individuals or households.
                </P>
                <P>
                    <E T="03">Annual Burden Hours:</E>
                     787.
                </P>
                <P>
                    <E T="03">Number of Respondents:</E>
                     23,600.
                </P>
                <P>
                    <E T="03">Responses per Respondent:</E>
                     1.
                </P>
                <P>
                    <E T="03">Annual Responses:</E>
                     23,600.
                </P>
                <P>
                    <E T="03">Average Burden per Response:</E>
                     2 minutes.
                </P>
                <P>
                    <E T="03">Frequency:</E>
                     On occasion.
                </P>
                <SIG>
                    <DATED>Dated: July 30, 2024.</DATED>
                    <NAME>Aaron T. Siegel,</NAME>
                    <TITLE>Alternate OSD Federal Register Liaison Officer, Department of Defense.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17168 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6001-FR-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF DEFENSE</AGENCY>
                <SUBAGY>Department of the Army</SUBAGY>
                <SUBJECT>Advisory Committee on Arlington National Cemetery Meeting Notice</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Department of the Army, DoD.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of open committee meeting.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>
                        The Department of the Army is publishing this notice to announce the following meeting of the Advisory Committee on Arlington National Cemetery (ACANC). This meeting is open to the public. For more information, please visit: 
                        <E T="03">https://www.arlingtoncemetery.mil/About/Advisory-Committee-on-Arlington-National-Cemetery/ACANC-Meetings.</E>
                    </P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>The ACANC will meet on Tuesday, August 20, 2024, from 9 a.m. to 2 p.m. eastern time in the Multipurpose Room of the Welcome Center at Arlington National Cemetery, Arlington, Virginia 22211.</P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Ms. Renea Yates, Designated Federal Officer (DFO) for the ACANC, or Mr. Matthew Davis, Alternate Designated Federal Officer (ADFO) for the ACANC, Arlington National Cemetery (ANC), Arlington, VA 22211; by email at 
                        <E T="03">matthew.r.davis.civ@army.mil;</E>
                         or by phone at 1-877-907-8585.
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>This meeting is being held under the provisions of the Federal Advisory Committee Act (FACA; 5 U.S.C. 10), the Government in the Sunshine Act of 1976 (5 U.S.C. 552b), and 41 CFR 102-3.150.</P>
                <P>
                    <E T="03">Purpose of the Meeting:</E>
                     The ACANC provides independent advice and recommendations to the Secretary of the Army on matters related to ANC, including, but not limited to, cemetery administration, the erection of memorials at the cemetery, and master planning for the cemetery. The Secretary of the Army may act on the Committee's advice and recommendations.
                </P>
                <P>
                    <E T="03">Agenda:</E>
                     The Committee will receive a status report of the planning for final disposition of the Confederate Memorial; receive a briefing on wait times for interment and the impact of military equine suspension for Arlington National Cemetery; receive a status update on the progress of objectives at Arlington National Cemetery, receive an update on the Southern Expansion progress, and receive a presentation on the Area Development Plan 1 Charette.
                </P>
                <P>
                    <E T="03">Public's Accessibility to the Meeting:</E>
                     Pursuant to FACA and 41 CFR 102-3.140 through 102-3.165, this meeting is open to the public.
                </P>
                <P>
                    <E T="03">Procedures for Attendance and Public Comment:</E>
                     To attend this meeting, contact Mr. Matthew Davis, the ADFO. (See the information listed in the 
                    <E T="02">FOR FURTHER INFORMATION CONTACT</E>
                     section; email is preferred.) Individuals will be asked to submit their full name, organization, email address, and phone number to attend. Public attendance will be via physical presence.
                </P>
                <P>
                    For additional information about public access procedures, contact Mr. Matthew Davis, the ADFO. (See the information listed in the 
                    <E T="02">FOR FURTHER INFORMATION CONTACT</E>
                     section; email is preferred.)
                </P>
                <P>
                    <E T="03">Written Comments and Statements:</E>
                     Pursuant to 5 U.S.C. 1009(a)(3), 41 CFR 102-3.105(j), and 41 CFR 102-3.140, the public or interested organizations may submit written comments or statements to the ACANC either in response to the stated agenda of the open meeting or regarding the ACANC's mission in general. Written comments or statements should be submitted to Mr. Matthew Davis, the ADFO. (See the information listed in the 
                    <E T="02">FOR FURTHER INFORMATION CONTACT</E>
                     section; email is preferred.) Each page of the comment or statement must include the author's name, title or affiliation, address, and daytime phone number. Written comments or statements being submitted in response to the agenda set forth in this notice must be received by the ADFO at least three business days prior to the meeting to be considered by the ACANC. Written comments or statements received after this date may not be provided to the ACANC until its next meeting. The DFO will review all timely written comments or statements with the ACANC Chairperson and will ensure such comments or statements are provided to all ACANC members before the meeting.
                </P>
                <P>
                    Pursuant to 41 CFR 102-3.140d, the ACANC is not obligated to allow any member of the public to speak or otherwise address the ACANC during the meeting. Members of the public may be permitted to make verbal comments during these meetings and if allowed, verbal comments may only be made at the time and in the manner described below. If a member of the public is interested in making a verbal comment at the open meeting, the individual 
                    <PRTPAGE P="63419"/>
                    must submit a request to the ADFO with a brief statement of the subject matter to be addressed by the comment. (See the information listed in the 
                    <E T="02">FOR FURTHER INFORMATION CONTACT</E>
                     section; email is preferred.) The request must be submitted to the ADFO at least three business days before the meeting. The ADFO will log each request in the order received. In consultation with the Chairperson(s), the DFO will determine whether the subject matter of each comment is relevant to the ACANC mission and/or to the agenda of this public meeting. Members of the public who asked to make a verbal comment and whose comments are deemed relevant under the process described above will be invited to speak in the order in which the ADFO received their request. The appropriate Chairperson(s) may allot a specific amount of time for verbal comments.
                </P>
                <SIG>
                    <NAME>James W. Satterwhite Jr.,</NAME>
                    <TITLE>Army Federal Register Liaison Officer.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17224 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 3711-02-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF DEFENSE</AGENCY>
                <SUBAGY>Department of the Army</SUBAGY>
                <DEPDOC>[Docket ID: USA-2024-HQ-0013]</DEPDOC>
                <SUBJECT>Proposed Collection; Comment Request</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Department of the Army, 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 U.S. Army Public Health Center 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 October 4, 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 05F16, 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 the U.S. Army Public Health Center, 8252 Blackhawk Road, ATTN: Joyce Woods, (MCHB-PHI-PMD), Aberdeen Proving Ground, MD 21010-5403, or call the Department of the Army Reports Clearance Officer at (703) 428-6440.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P/>
                <P>
                    <E T="03">Title; Associated Form; and OMB Number:</E>
                     Application for Temporary Food Establishment; DD Form 2970; OMB Control Number 0702-0132.
                </P>
                <P>
                    <E T="03">Needs and Uses:</E>
                     The information collection requirement is necessary for the installation Preventive Medicine or Public Health Activity to evaluate a food vendor's ability to prepare and dispense safe food on the installation. The DD Form 2970, submitted one time by a food vendor requesting to operate a food establishment on a military installation, characterizes the types of foods, daily volume of food, supporting food equipment, and sanitary controls. Approval to operate the food establishment is determined by the installation's medical authority; the Preventive Medicine or Public Health Activity conducts an operational assessment based on the food safety criteria prescribed in the Tri-Service Food Code (TB MED 530/NAVMED P-5010-1/AFMAN 48-147_IP). Food vendors who are deemed inadequately prepared to provide safe food service are disapproved for operating on the installation.
                </P>
                <P>
                    <E T="03">Affected Public:</E>
                     Business or other for-profit; Not-for-profit institutions.
                </P>
                <P>
                    <E T="03">Annual Burden Hours:</E>
                     23.
                </P>
                <P>
                    <E T="03">Number of Respondents:</E>
                     91.
                </P>
                <P>
                    <E T="03">Responses per Respondent:</E>
                     1.
                </P>
                <P>
                    <E T="03">Annual Responses:</E>
                     91.
                </P>
                <P>
                    <E T="03">Average Burden per Response:</E>
                     15 minutes.
                </P>
                <P>
                    <E T="03">Frequency:</E>
                     On occasion.
                </P>
                <SIG>
                    <DATED>Dated: July 30, 2024.</DATED>
                    <NAME>Aaron T. Siegel,</NAME>
                    <TITLE>Alternate OSD Federal Register Liaison Officer, Department of Defense. </TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17164 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6001-FR-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF DEFENSE</AGENCY>
                <SUBAGY>Department of the Army</SUBAGY>
                <DEPDOC>[Docket ID: USA-2024-HQ-0012]</DEPDOC>
                <SUBJECT>Proposed Collection; Comment Request</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Department of the Army, 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 Army &amp; Air Force Exchange Service (Exchange) 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 October 4, 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 05F16, 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 
                        <PRTPAGE P="63420"/>
                        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 Army &amp; Air Force Exchange Service, Office of the General Counsel, Compliance Division, ATTN: Teresa Schreurs, 3911 South Walton Walker Blvd., Dallas, TX 75236-1598, through email to 
                        <E T="03">PrivacyManager@aafes.com,</E>
                         or call the Exchange Compliance Division at 800-967-6067, Option 5.
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P/>
                <P>
                    <E T="03">Title; Associated Form; and OMB Number:</E>
                     Exchange Employee Travel Files; OMB Control Number 0702-0131.
                </P>
                <P>
                    <E T="03">Needs and Uses:</E>
                     The information collection requirement is necessary to process official Permanent Change of Station travel requests for Exchange civilian employees; to determine eligibility of the employee's dependents to travel; to obtain the necessary clearance where foreign travel is involved, including assisting individuals in applying for passports, visas, and counseling where proposed travel involves visiting or transitioning to communist countries and danger zones. Respondents are Exchange employees, family members, and dependents that are authorized to engage in Exchange government travel. The completed forms are necessary to obtain this authorization and to provide the employee and their dependents with assistance to obtain visas, passports, security clearance, and other travel documents as required.
                </P>
                <P>
                    <E T="03">Affected Public:</E>
                     Individuals or households.
                </P>
                <P>
                    <E T="03">Annual Burden Hours:</E>
                     125.
                </P>
                <P>
                    <E T="03">Number of Respondents:</E>
                     250.
                </P>
                <P>
                    <E T="03">Responses per Respondent:</E>
                     1.
                </P>
                <P>
                    <E T="03">Annual Responses:</E>
                     250.
                </P>
                <P>
                    <E T="03">Average Burden per Response:</E>
                     30 minutes.
                </P>
                <P>
                    <E T="03">Frequency:</E>
                     On occasion.
                </P>
                <SIG>
                    <DATED>Dated: July 30, 2024.</DATED>
                    <NAME>Aaron T. Siegel,</NAME>
                    <TITLE>Alternate OSD Federal Register Liaison Officer, Department of Defense. </TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17170 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6001-FR-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF DEFENSE</AGENCY>
                <SUBAGY>Department of the Army</SUBAGY>
                <DEPDOC>[Docket ID: USA-2024-HQ-0014]</DEPDOC>
                <SUBJECT>Proposed Collection; Comment Request</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Department of the Army, 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 Army &amp; Air Force Exchange Service (Exchange) 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 October 4, 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 05F16, 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 Army &amp; Air Force Exchange Service, Office of the General Counsel, Compliance Division, ATTN: Teresa Schreurs, 3911 South Walton Walker Blvd., Dallas, TX 75236-1598, through email to 
                        <E T="03">PrivacyManager@aafes.com,</E>
                         or call the Exchange Compliance Division at 800-967-6067, Option 5.
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P/>
                <P>
                    <E T="03">Title; Associated Form; and OMB Number:</E>
                     Exchange Employment Applications; Exchange Forms 1200-718 and 1200-026; OMB Control Number 0702-0133.
                </P>
                <P>
                    <E T="03">Needs and Uses:</E>
                     This information collection covers the documentation related to the employment of individuals to the Exchange within the Continental United States of America and Exchange facilities outside the Continental United States of America. The collection allows the Exchange to capture the essential information required to evaluate applicants for Exchange civilian opportunities in order to hire the best, qualified individuals empowering the Exchange's mission of enhancing the quality of life for members of the U.S. Military.
                </P>
                <P>
                    <E T="03">Affected Public:</E>
                     Individuals or households.
                </P>
                <P>
                    <E T="03">Annual Burden Hours:</E>
                     55,830.
                </P>
                <P>
                    <E T="03">Number of Respondents:</E>
                     111,660.
                </P>
                <P>
                    <E T="03">Responses per Respondent:</E>
                     1.
                </P>
                <P>
                    <E T="03">Annual Responses:</E>
                     111,660.
                </P>
                <P>
                    <E T="03">Average Burden per Response:</E>
                     30 minutes.
                </P>
                <P>
                    <E T="03">Frequency:</E>
                     On occasion.
                </P>
                <SIG>
                    <DATED>Dated: July 30, 2024.</DATED>
                    <NAME>Aaron T. Siegel,</NAME>
                    <TITLE>Alternate OSD Federal Register Liaison Officer, Department of Defense.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17176 Filed 8-2-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>
                <SUBJECT>Defense Advisory Committee on Women in the Services; Notice of Federal Advisory Committee Meeting</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Office of the Under Secretary of Defense for Personnel and Readiness, Department of Defense (DoD). </P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of Federal advisory committee meeting. </P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The DoD is publishing this notice to announce that the following Federal advisory committee meeting of the Defense Advisory Committee on Women in the Services (DACOWITS) will take place. </P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>
                        DACOWITS will hold an open to the public meeting—Tuesday, September 10, 2024, from 8:00 a.m. to 11:30 a.m. Eastern Time (ET). 
                        <PRTPAGE P="63421"/>
                        Wednesday, September 11, 2024, from 8:00 a.m. to 2:30 p.m. (ET).
                    </P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>The meeting will take place at the Association of the United States Army Conference Center, located at 2425 Wilson Boulevard, Arlington, Virginia 22201. The meeting will also be streamed virtually. To participate in the meeting, see the Meeting Accessibility section for instructions. </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Colonel Seana Jardin, Designated Federal Officer (DFO), (703) 697-2122 (voice), 
                        <E T="03">seana.m.jardin.mil@army.mil</E>
                         (email). The most up-to-date changes to the meeting agenda can be found on the website: 
                        <E T="03">https://dacowits.defense.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>This meeting is being held under the provisions of chapter 10 of title 5, United States Code (U.S.C.) (commonly known as the “Federal Advisory Committee Act” or “FACA”), 5 U.S.C. 552b (commonly known as the “Government in the Sunshine Act”), and 41 Code of Federal Regulations (CFR) 102-3.140 and 102-3.150.</P>
                <P>
                    <E T="03">Availability of Materials for the Meeting:</E>
                     Additional information, including the agenda or any updates to the agenda, is available at the DACOWITS website, 
                    <E T="03">https://dacowits.defense.gov/.</E>
                     Materials presented in the meeting may also be obtained on the DACOWITS website. 
                </P>
                <P>
                    <E T="03">Purpose of the Meeting:</E>
                     The purpose of the meeting is for the DACOWITS to receive briefings and have discussions on topics related to the recruitment, retention, employment, integration, well-being, and treatment of women in the Armed Forces of the United States. 
                </P>
                <P>
                    <E T="03">Agenda:</E>
                     Tuesday, September 10, 2024, from 8:00 a.m. to 11:30 a.m.—Welcome; Introductions; Announcements; Request for Information Status Update; Briefing from the Marine Corps on Dual-Military Couples; Briefings from the Defense Health Agency and the Military Services on Military Treatment Facilities and Women's Health Care; and a Public Comment Period from 11:15 a.m. to 11:30 a.m.
                </P>
                <P>Wednesday, September 11, 2024, from 8:00 a.m. to 2:30 p.m.—Welcome; Introductions; Announcements; Committee Votes on Recommendations to the Secretary of Defense.</P>
                <P>
                    <E T="03">Meeting Accessibility:</E>
                     Pursuant to 5 U.S.C. 552b and 41 CFR 102-3.140 through 102-3.165, this meeting is open to the public, subject to availability of space, from 8:00 a.m. to 11:30 a.m. on September 10, 2024, and from 8:00 a.m. to 2:30 p.m. on September 11, 2024. The meeting will also be streamed by videoconference. The number of participants is limited and is on a first-come basis. Any member of the public who wishes to participate via videoconference must register by contacting DACOWITS at 
                    <E T="03">osd.pentagon.ousd-p-r.mbx.dacowits@mail.mil</E>
                     or by contacting Mr. Robert Bowling at (703) 380-0116 no later than Tuesday, September 3, 2024. Once registered, the videoconference information will be provided.
                </P>
                <P>
                    <E T="03">Special Accommodations:</E>
                     Individuals requiring special physical or electronic accommodations to access the public meeting should contact Mr. Robert Bowling no later than Tuesday, September 3, 2024, so appropriate arrangements can be made. 
                </P>
                <P>
                    <E T="03">Written Statements:</E>
                     Pursuant to 41 CFR 102-3.140, and section 10(a)(3) of the FACA, interested persons may submit a written statement to the DACOWITS pertaining to its overall mission/scope or in response to the approved meeting agenda announced in this notice. Individuals submitting a written statement must submit their statement no later than 5:00 p.m., Tuesday, September 3, 2024, to Mr. Robert Bowling (703) 380-0116 (voice) or to 
                    <E T="03">osd.pentagon.ousd-p-r.mbx.dacowits@mail.mil.</E>
                     Mailing address is 4800 Mark Center Drive, Suite 06E22, Alexandria, VA 22350. Members of the public interested in making an oral statement must submit a written statement of their comments. If a statement is not received by Tuesday, September 3, 2024, it may not be provided to or considered by the Committee during this quarterly business meeting. After reviewing the written statements, the Chair and the DFO will determine if the requesting persons are permitted to make an oral presentation. Oral presentations will be limited to two minutes. The DFO will review all timely submissions with the DACOWITS Chair and will provide to all members of the Committee. 
                </P>
                <SIG>
                    <DATED>Dated: July 31, 2024.</DATED>
                    <NAME>Aaron T. Siegel, </NAME>
                    <TITLE>Alternate OSD Federal Register Liaison Officer, Department of Defense.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17247 Filed 8-2-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-0011]</DEPDOC>
                <SUBJECT>Submission for OMB Review; 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>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 September 4, 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>
                        Reginald Lucas, (571) 372-7574, 
                        <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>
                     Defense Biometric Identification System (DBIDS) Registration Application; OMB Control Number 0704-0455.
                </P>
                <P>
                    <E T="03">Type of Request:</E>
                     Extension.
                </P>
                <P>
                    <E T="03">Number of Respondents:</E>
                     2,500,000.
                </P>
                <P>
                    <E T="03">Responses per Respondent:</E>
                     1.
                </P>
                <P>
                    <E T="03">Annual Responses:</E>
                     2,500,000.
                </P>
                <P>
                    <E T="03">Average Burden per Response:</E>
                     7.5 minutes.
                </P>
                <P>
                    <E T="03">Annual Burden Hours:</E>
                     312,500.
                </P>
                <P>
                    <E T="03">Needs and Uses:</E>
                     The information collection requirement is necessary to obtain and record the biographic and biometric data connected with positively identifying identity, eligibility for access, and fitness within DBIDS and shared with Identity Matching Engine for Security and Analysts (IMESA)/Interoperability Layer Service (IoLS). The form data is used in the determination of access at DBIDS sites and affiliated systems through use of IMESA/IoLS.
                </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>
                     Ms. Jasmeet Seehra.
                </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 
                    <PRTPAGE P="63422"/>
                    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>
                     Mr. Reginald Lucas.
                </P>
                <P>
                    Requests for copies of the information collection proposal should be sent to Mr. Lucas at 
                    <E T="03">whs.mc-alex.esd.mbx.dd-dod-information-collections@mail.mil.</E>
                </P>
                <SIG>
                    <DATED>Dated: July 30, 2024.</DATED>
                    <NAME>Aaron T. Siegel,</NAME>
                    <TITLE>Alternate OSD Federal Register Liaison Officer, Department of Defense.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17177 Filed 8-2-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-0093]</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 Office of 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 October 4, 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 05F16, 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>
                     TRICARE Young Adult Application; DD Form 2947; OMB Control Number 0720-0049.
                </P>
                <P>
                    <E T="03">Needs and Uses:</E>
                     The Ike Skelton National Defense Authorization Act for Fiscal Year 2011, Section 702, aligns TRICARE Program eligibility by providing a means to extend the age of eligibility of TRICARE dependents from age 21 or 23 up to age 26 to allow the purchase of extended dependent medical coverage across existing TRICARE program options (Select and Prime). This is consistent with the intent of the Patient Protection and Affordable Care Act, the implementing Health and Human Services regulations, and the limitations of Chapter 55 of Title 10. Section 702 allows qualified adult children not eligible for medical coverage at age 21 (23 if enrolled in a full-time course of study at an institution of higher learning approved by the Secretary of Defense) and are under age 26 to qualify to purchase medical coverage unless the dependent is enrolled in or eligible to purchase employer sponsored insurance per section 5000A(f)(2) of the Internal Revenue Code of 1986 or is married. The dependents shall be able to purchase either the TRICARE Prime or Select benefits depending on if they meet specific program requirements and the availability of a desired plan in their geographic location.
                </P>
                <P>
                    <E T="03">Affected Public:</E>
                     Individuals or households.
                </P>
                <P>
                    <E T="03">Annual Burden Hours:</E>
                     677.
                </P>
                <P>
                    <E T="03">Number of Respondents:</E>
                     2,709.
                </P>
                <P>
                    <E T="03">Responses per Respondent:</E>
                     1.
                </P>
                <P>
                    <E T="03">Annual Responses:</E>
                     2,709.
                </P>
                <P>
                    <E T="03">Average Burden per Response:</E>
                     15 minutes.
                </P>
                <SIG>
                    <DATED>Dated: July 31, 2024.</DATED>
                    <NAME>Aaron T. Siegel,</NAME>
                    <TITLE>Alternate OSD Federal Register Liaison Officer, Department of Defense.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17211 Filed 8-2-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-0092]</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 October 4, 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 05F16, 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 
                        <PRTPAGE P="63423"/>
                        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>
                     TRICARE DoD/CHAMPUS Medical Claim Patient's Request for Medical Payment; DD Form 2642; OMB Control Number 0720-0006.
                </P>
                <P>
                    <E T="03">Needs and Uses:</E>
                     The DD-2642, “TRICARE DoD/Civilian Health and Medical Program of the Uniformed Services (CHAMPUS) Medical Claim Patient's Request for Medical Payment” form is used by TRICARE beneficiaries to claim reimbursement for medical expenses under the TRICARE Program CHAMPUS. The information collected will be used by TRICARE to determine beneficiary eligibility, other health insurance liability, certification that the beneficiary has the received care, and reimbursement for medical services received.
                </P>
                <P>
                    <E T="03">Affected Public:</E>
                     Individuals or households.
                </P>
                <P>
                    <E T="03">Annual Burden Hours:</E>
                     207,500.
                </P>
                <P>
                    <E T="03">Number of Respondents:</E>
                     830,000.
                </P>
                <P>
                    <E T="03">Responses per Respondent:</E>
                     1.
                </P>
                <P>
                    <E T="03">Annual Responses:</E>
                     830,000.
                </P>
                <P>
                    <E T="03">Average Burden per Response:</E>
                     15 minutes.
                </P>
                <SIG>
                    <DATED>Dated: July 31, 2024.</DATED>
                    <NAME>Aaron T. Siegel,</NAME>
                    <TITLE>Alternate OSD Federal Register Liaison Officer, Department of Defense. </TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17210 Filed 8-2-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>
                <SUBJECT>Renewal of Department of Defense Federal Advisory Committees—Army Education Advisory Committee</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Department of Defense (DoD).</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Renewal of a Federal advisory committee.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The DoD is publishing this notice to announce that it is renewing the Army Education Advisory Committee (AEAC).</P>
                </SUM>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Jim Freeman, Advisory Committee Management Officer for the Department of Defense, 703-692-5952.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    The AEAC is being renewed in accordance with chapter 10 of title 5, United States Code (U.S.C.) (commonly known as the “Federal Advisory Committee Act” or “FACA”) and 41 Code of Federal Regulations (CFR) 102-3.50(a). The charter and contact information for the Committee's Designated Federal Officer (DFO) are found at 
                    <E T="03">https://www.facadatabase.gov/FACA/apex/FACAPublicAgencyNavigation.</E>
                </P>
                <P>The AEAC provides the Secretary of Defense, Deputy Secretary of Defense (“the DoD Appointing Authority”), and the Secretary of the Army independent advice and recommendations on U.S. Army educational matters. The AEAC will focus on matters pertaining to the educational doctrinal, and research policies and activities of the U.S. Army's educational programs, to include the U.S. Army's joint professional military education programs. The AEAC will assess and provide independent advice and recommendations across the spectrum of educational policies, school curricula, educational philosophy and objectives, program effectiveness, facilities, staff and faculty, instructional methods, and other aspects of the organization and management of these programs. The AEAC will also provide independent advice and recommendations on matters pertaining to the Army Historical Program and the role and mission of the U.S. Army Center of Military History, particularly as they pertain to the study and use of military history in Army schools. The AEAC shall be composed of 15 members. The membership will include: (a) fourteen individuals who are eminent authorities in the fields of defense, management, leadership, and academia, including those who are deemed to be historical scholars; and (b) the Chief Historian of the Army, U.S. Army, Center of Military History.</P>
                <P>Individual AEAC members are appointed according to DoD policy and procedures and serve a term of service of one-to-four years with annual renewals. One member will be appointed as Chair of the AEAC. No member, unless approved according to DoD policy and procedures, may serve more than two consecutive terms of service on the AEAC, or serve on more than two DoD Federal advisory committees at one time.</P>
                <P>AEAC members who are not full-time or permanent part-time Federal civilian officers, employees, or active-duty members of the Uniformed Services will be appointed as experts or consultants, pursuant to 5 U.S.C. 3109, to serve as special government employee members. AEAC members who are full-time or permanent part-time Federal civilian officers or employees, or active-duty members of the Uniformed Services, will be appointed pursuant to 41 CFR 102-3.130(a), to serve as regular government employee members.</P>
                <P>All members of the AEAC are appointed to provide advice on the basis of their best judgment without representing any particular point of view and in a manner that is free from conflict of interest. Except for reimbursement of official AEAC-related travel and per diem, members serve without compensation.</P>
                <P>The public or interested organizations may submit written statements to the AEAC membership about the AEAC's mission and functions. Written statements may be submitted at any time or in response to the stated agenda of planned meeting of the AEAC. All written statements shall be submitted to the DFO for the AEAC, and this individual will ensure that the written statements are provided to the membership for their consideration.</P>
                <SIG>
                    <DATED>Dated: July 31, 2024.</DATED>
                    <NAME>Aaron T. Siegel,</NAME>
                    <TITLE>Alternate OSD Federal Register Liaison Officer, Department of Defense.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17228 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6001-FR-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF DEFENSE</AGENCY>
                <SUBAGY>Department of the Navy</SUBAGY>
                <DEPDOC>[Docket ID: USN-2024-HQ-0005]</DEPDOC>
                <SUBJECT>Submission for OMB Review; Comment Request</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Department of the Navy (DoN), 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 September 4, 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/
                            <PRTPAGE P="63424"/>
                            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>
                        Reginald Lucas, (571) 372-7574, 
                        <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>
                     Male Survivors of Sexual Assault—Investigating Challenges Around Seeking Help (MOSAIC); OMB Control Number 0703-MSIC.
                </P>
                <P>
                    <E T="03">Type of Request:</E>
                     New collection.
                </P>
                <P>MOSAIC study online sign-up form.</P>
                <P>
                    <E T="03">Number of Respondents:</E>
                     20.
                </P>
                <P>
                    <E T="03">Responses per Respondent:</E>
                     1.
                </P>
                <P>
                    <E T="03">Annual Responses:</E>
                     20.
                </P>
                <P>
                    <E T="03">Average Burden per Response:</E>
                     10 minutes.
                </P>
                <P>
                    <E T="03">Annual Burden Hours:</E>
                     3.33 hours.
                </P>
                <HD SOURCE="HD1">Mosaic Study Interview</HD>
                <P>
                    <E T="03">Number of Respondents:</E>
                     20.
                </P>
                <P>
                    <E T="03">Responses per Respondent:</E>
                     1.
                </P>
                <P>
                    <E T="03">Annual Responses:</E>
                     20.
                </P>
                <P>
                    <E T="03">Average Burden per Response:</E>
                     1 hour.
                </P>
                <P>
                    <E T="03">Annual Burden Hours:</E>
                     20.
                </P>
                <HD SOURCE="HD1">Total</HD>
                <P>
                    <E T="03">Number of Respondents:</E>
                     20.
                </P>
                <P>
                    <E T="03">Annual Responses:</E>
                     40.
                </P>
                <P>
                    <E T="03">Annual Burden Hours:</E>
                     23.
                </P>
                <P>
                    <E T="03">Needs and Uses:</E>
                     Given the devastating effects of Military Sexual Trauma (MST) and limited information on male MST specifically, the U.S. Congress specified a requirement to improve the prevention of and response to sexual trauma affecting male service members in the National Defense Authorization Act for Fiscal Year 2016 (Pub. L. 114-92). Furthermore, the DoD developed a formalized plan of action to improve prevention and response efforts for male MST. Despite these efforts and consistent with prior research, DoD reports found that active duty men are substantially less likely to report MST relative to active duty women counterparts. As part of the DoD-wide effort to promote help-seeking for sexual assault survivors, the DoN Office of Force Resiliency (OFR) developed and recently updated the Prevention Plan of Action (PPoA) (aka Prevention Plan of Action 2.0, 2022-2024; PPoA 2.0). The PPoA 2.0 is a strategy framework leveraging public health science in military environments to prevent sexual assault in the military and improve response efforts. As part of this initiative, OFR commissioned this study (Agreement #NMR-24-11717) to investigate the help-seeking among men who experienced military sexual violence (
                    <E T="03">i.e.,</E>
                     sexual assault or sexual harassment). The present study addresses this requirement by conducting interviews with men who have experienced military sexual violence.
                </P>
                <P>
                    <E T="03">Affected Public:</E>
                     Individuals or households.
                </P>
                <P>
                    <E T="03">Frequency:</E>
                     Once.
                </P>
                <P>
                    <E T="03">Respondent's Obligation:</E>
                     Voluntary.
                </P>
                <P>
                    <E T="03">OMB Desk Officer:</E>
                     Ms. Jasmeet Seehra.
                </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>
                     Mr. Reginald Lucas.
                </P>
                <P>
                    Requests for copies of the information collection proposal should be sent to Mr. Lucas at 
                    <E T="03">whs.mc-alex.esd.mbx.dd-dod-information-collections@mail.mil.</E>
                </P>
                <SIG>
                    <DATED>Dated: July 30, 2024.</DATED>
                    <NAME>Aaron T. Siegel,</NAME>
                    <TITLE>Alternate OSD Federal Register Liaison Officer, Department of Defense.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17178 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 3810-FF-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">DEPARTMENT OF ENERGY</AGENCY>
                <SUBJECT>Record of Decision: Issuance of a Loan Guarantee to Holtec Palisades, LLC for General Restoration and Maintenance Activities of the Palisades Nuclear Plant</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Loan Programs Office (LPO), U.S. Department of Energy.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Record of decision (ROD).</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The U.S. Department of Energy (DOE) announces its decision to issue a loan guarantee under the Energy Policy Act of 2005 (EPAct 2005), as amended, specifically the Energy Infrastructure Reinvestment Program, to Holtec Palisades, LLC., (Holtec) for general restoration and maintenance activities (Project), consistent with the Nuclear Regulatory Commission (NRC) Renewed Facility Operating License Number DPR-20. The general restoration and maintenance activities would support the potential future resumption of power generation activities at the Palisades Nuclear Plant (Palisades or PNP), an 800-MW electric nuclear generation station in Covert Township, Michigan. Holtec has initiated an exemption request, a license transfer request, and license amendment requests with NRC, that, if approved, would allow the resumption of power generation and operation until 2031, and Holtec intends to submit a subsequent license extension request to the NRC to allow power generation from 2031 to 2051.</P>
                </SUM>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Copies of this ROD and the Final EIS may be obtained by accessing these documents and additional information about DOE's Loan Programs website at 
                        <E T="03">https://www.energy.gov/lpo/eis-0562-palisades-nuclear-restart-project-van-buren-county-michigan,</E>
                         or LPO's NEPA Program website at 
                        <E T="03">https://www.energy.gov/lpo/environmental-compliance-1.</E>
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Alicia Williamson, NEPA Document Manager, Technical and Environmental Division, Loan Programs Office (LP-30), U.S. Department of Energy, 1000 Independence Ave. SW, Washington, DC 20585, telephone (202) 586-7272; email 
                        <E T="03">Alicia.Williamson@hq.doe.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    The environmental impacts of general restoration and maintenance activities at PNP were analyzed pursuant to the National Environmental Policy Act (NEPA) in the 
                    <E T="03">DOE/EIS-0562: Final Environmental Impact Statement, Proposed Palisades Nuclear Restart Project, Van Buren County, Michigan</E>
                     (89 FR 53659, June 27, 2024).
                </P>
                <P>The Project would entail general restoration and maintenance activities at PNP, consistent with the NRC Renewed Facility Operating License Number DPR-20. DOE LPO's review and adoption of the NRC NEPA documents covers only general restoration and maintenance activities, and the potential use of a DOE loan guarantee for PNP refueling, power ascension, and power generation would not occur until the completion of the NRC NEPA evaluation analyzing the same.</P>
                <P>
                    <E T="03">NEPA Review:</E>
                     Prior to DOE LPO consideration of a loan guarantee for the Project, PNP ceased operations, the nuclear fuel was removed, and PNP entered decommissioning mode in May 2022. The nuclear fuel was placed in the established onsite spent fuel pool, but no structural dismantling of PNP has occurred, and the equipment is still in place and intact. Palisades was acquired by Holtec in June 2022, who now 
                    <PRTPAGE P="63425"/>
                    intends to restore PNP and resume power generation activities. Holtec has initiated an exemption request, a license transfer request, and license amendment requests processes with the NRC, that if approved, would allow the reactor to be re-fueled and the resumption of power generation and operation until 2031. In addition, Holtec intends to submit a Subsequent License Renewal (SLR) application to NRC, that if granted, would allow power generation until at least 2051.
                </P>
                <P>Holtec is pursuing a reauthorization of power operations at PNP within the existing NRC regulatory framework, which would allow the reactor to be refueled and resume power generation operations through March 2031. In 2007, the NRC granted Palisades a 20-year Renewed Facility Operating License (No. DPR-20), which extended the period of PNP operations until March 2031. The NRC completed a safety analysis review and in compliance with NEPA, issued NUREG-1437, Supplement 27, Generic Environmental Impact Statement for License Renewal of Nuclear Plants, Regarding Palisades Nuclear Plant, Draft Report (SEIS) in February 2006 (71 FR 9541), followed by the Final SEIS in October 2006 (71 FR 61967). The SEIS analyzed the environmental impacts of PNP operations from March 2011 through March 2031. The NRC's Record of Decision (ROD) (72 FR 3168) and reactor facility operating license approval for the 20- year extended operations period was issued in January 2007.</P>
                <P>DOE was not a cooperating agency in the development of the NRC SEIS. DOE LPO conducted a review of the NRC environmental documents related to the licensing of PNP, in accordance with 10 CFR 1021.200(d). DOE's proposed action of issuing a loan guarantee to support the general restoration and maintenance activities was analyzed in the NRC SEIS. Based on its independent evaluation of the NRC's 2006 SEIS, DOE has determined that the documentation satisfies DOE NEPA procedures for the general restoration and maintenance activities of PNP. Accordingly, DOE adopted and recirculated the 2006 NRC Final SEIS as a DOE Final EIS (DOE/EIS-0562). Activities associated with PNP refueling and repowering are not yet ripe and are the subject of an NRC environmental review, with DOE as a cooperating agency. Consequently, the potential use of a DOE loan guarantee for PNP refueling, repowering, and power generation would not occur until the completion of the NRC NEPA evaluation analyzing the potential environmental impacts of refueling and repowering, and the associated NRC approvals of Holtec's exemption request from 10 CFR 50.82(a)(2), license transfer request, and license amendment requests.</P>
                <P>DOE is a NEPA cooperating agency with the NRC on its environmental review for the exemption request, a license transfer request, and license amendment requests and will cooperate with the NRC on the subsequent license renewal process, thereby tiering its environmental review process to focus on the issues that are ripe for decision and inform future decisions regarding additional Federal financial assistance. At the conclusion of each NRC environmental review and approval processes, DOE would publish a Record of Decision in support of any future Federal financial assistance associated with resumption of power generation and operation extending beyond 2031.</P>
                <P>
                    <E T="03">Alternatives Considered:</E>
                     DOE's decision in this ROD is whether or not to issue a loan guarantee to Holtec for general restoration and maintenance activities in support of repowering PNP. Accordingly, DOE's alternatives are: (1) to issue a loan guarantee to Holtec for the Proposed Action, or (2) not issue a loan guarantee to Holtec (No-Action Alternative).
                </P>
                <P>
                    <E T="03">Environmental Preferable Alternative:</E>
                     DOE reviewed both alternatives to identify the environmentally preferable alternative and considers the issuance of a loan guarantee to Holtec for the Proposed Action as the environmentally preferable alternative. This alternative offers environmental benefits consistent with the statutory objectives of Section 1706 of EPAct 2005, as amended, specifically the Energy Infrastructure Reinvestment Program, which includes repowering of energy infrastructure that has ceased operations and reduces greenhouse gas emissions. Compared to fossil-fuel power sources producing the same amount of power, carbon dioxide emission rates from the Project would be considerably less (see Section 8.2.1 of DOE/EIS-0562). This chosen alternative does not limit consideration of alternatives for future NEPA reviews related to the Proposed Action.
                </P>
                <P>
                    <E T="03">Environmental Justice:</E>
                     Updated guidance regarding environmental justice (
                    <E T="03">e.g.,</E>
                     Executive Order 14096, 
                    <E T="03">Revitalizing Our Nations Commitment to Environmental Justice</E>
                    ) was not in place when NRC issued the Final SEIS. For the Palisades review, DOE/EIS-0562 examined the geographic distribution of minority and low-income populations within 50 miles of the site, using data from the 2000 U.S. Census Bureau. The analysis was supplemented by discussions with the local authorities from the Van Buren County planning department and social service agencies. The analysis concluded PNP does not disproportionately result in high and adverse human health or environmental impacts on minority or low-income populations. As a result, DOE concluded the analysis encompasses the scope of the DOE proposed action, as the current NRC license for PNP remains in effect through 2031. Nevertheless, future environmental analyses evaluating the refueling and repowering activities for the Palisades restart project will include an environmental justice review using the most up-to-date Federal guidelines.
                </P>
                <P>
                    <E T="03">Floodplain Statement of Findings:</E>
                     The DOE/EIS-0562 considered the relevant information for a floodplains and wetlands assessment pursuant to 10 CFR part 1022. The Proposed Action is not within a 100-year floodplain and because no major construction will take place, there would be no redirection or alteration in patterns of surrounding water, sediment transport or wetlands onsite. DOE/EIS-0562 Sections 2.2.6, 4.2, and 4.28 contain the relevant analyses on floodplains and wetlands. Furthermore, in 2019, the NRC conducted a Flooding Focused Evaluation at the Palisades plant which required the facility to reevaluate flood hazards for the site using more current methods and new regulatory guidance used by the NRC staff. This process concluded that Palisades had demonstrated that effective flood protection exists in the event of a beyond-design-basis external flooding event (Palisades Nuclear Plant-Staff Assessment of Flooding Focused Evaluation (EPID No. L-2018-JLD-0015, January 19, 2019).
                </P>
                <P>The NRC's current licensing basis is designed to address the risks associated with natural hazards such as climate change. Additionally, as noted in the Environmental Preferable Alternative section of this document, the greenhouse gases emitted from the Project would be less than a reasonable alternative.</P>
                <P>
                    <E T="03">Consultation Requirements:</E>
                     DOE was not a cooperating agency with NRC during its development of the NRC SEIS; therefore, DOE completed its own environmental compliance reviews and consultations. Specifically, DOE consulted with the Michigan State Historical Preservation Office (SHPO) and the U.S. Fish and Wildlife Service (USFWS). Additionally, the DOE reviewed the NRC's Final SEIS and supporting documentation and related surveys, studies, and consultations.
                </P>
                <P>
                    By letter dated May 20, 2024, the Michigan SHPO concurred with DOE's 
                    <PRTPAGE P="63426"/>
                    finding of no historic properties effected within the area of potential effect associated with this undertaking pursuant to Section 106 of the National Historic Preservation Act. DOE also sent a NEPA notice regarding the proposed Federal financial assistance for the general restoration and maintenance activities at PNP to Federally recognized Native American Tribes in the area or with indigenous ties to the area to identify Tribal interest and provide an opportunity to make comments or express concerns. Additionally, each Tribe was contacted by telephone to ensure receipt and respond to any immediate questions or concerns. No immediate questions or concerns were relayed by the Tribes.
                </P>
                <P>
                    By letter dated, May 23, 2024, the US FWS confirmed consultation was not needed for the project based on the “no effect” and “not likely to adversely affect” (NLAA) determinations of the following threatened and endangered species located in the vicinity of PNP: Eastern Massasauga rattlesnake (
                    <E T="03">Sistrurus catenatus</E>
                    )-NLAA; Indiana Bat (
                    <E T="03">Myotis soldalis</E>
                    )-no effect; Mitchell's Satyr Butterfly (
                    <E T="03">Neonympha mitchellii mitchellii</E>
                    )-no effect; Monarch Butterfly (
                    <E T="03">Danaus plexippus</E>
                    )-no effect; Piping Plover (
                    <E T="03">Charadruis melodus</E>
                    )-NLAA; Pitcher's Thistle (
                    <E T="03">Cirsium pitcher</E>
                    )-NLAA; Rufa Red Know (
                    <E T="03">Calidris canutus rufa</E>
                    )-NLAA; Tricolored Bat (
                    <E T="03">Perimyotis subflavus</E>
                    )-no effect; and Whooping Crane (
                    <E T="03">Grus americana</E>
                    )-no effect. Finally, through its review, DOE determined that NRC completed the Coastal Zone Management Act Federal Consistency Certification, which is documented in Appendix E of Final DOE/EIS-0562. Hence, DOE has fulfilled its consultation responsibilities under NHPA and ESA for restoration and maintenance activities related to the general restoration and maintenance activities of PNP.
                </P>
                <P>
                    <E T="03">Final DOE/EIS-0562 Review Period:</E>
                     The Notice of Availability of the Final DOE/EIS-0562 and the Adoption Notice were published in the 
                    <E T="04">Federal Register</E>
                     on March 1, 2024 (89 FR 15199). The review period of the EIS was from March 1 to April 1, 2024. DOE received one submittal from the public during the review period. The inquiry requested information regarding the LPO's NEPA process, a copy of project documentation, and a DOE point of contact for the project. DOE provided the requested information, and has concluded that no new information or circumstances has been submitted that would warrant preparation of a supplemental EIS, or show that the Project would affect the quality of the human environment not already encompassed by the analysis considered in the Final DOE/EIS-0562, or considered in the preparation of this ROD.
                </P>
                <P>
                    <E T="03">Decision:</E>
                     DOE has decided to issue a loan guarantee to Holtec Palisades, LLC for the general restoration and maintenance activities in support of repowering PNP, an 800-MW electric nuclear generation station in Covert Township, Michigan. The Project would entail the general restoration and maintenance activities in support of repowering PNP in accordance with the existing NRC Renewed Facility Operating License Number DPR-20. Approval of the loan guarantee responds to the DOE purpose and need pursuant to Section 1706 of EPAct 2005, as amended, specifically the Energy Infrastructure Reinvestment Program. DOE's Proposed Action evaluated in this ROD supports the general restoration and maintenance activities at PNP analyzed within the Final DOE/EIS-0562. Activities associated with PNP refueling, repowering and operations to 2031, and operation from 2031-2051 (via SLR) are not yet ripe for environmental analysis or decisions, are not the subject of this ROD, and will be the subject of current and future NRC and DOE environmental reviews.
                </P>
                <P>
                    <E T="03">Mitigation:</E>
                     All DOE loan guarantee agreements require that the borrower comply with all applicable environmental laws and related requirements. For the Project, this would include conditions and requirements related to authorizations and approvals within the NRC's 2006 ROD, all permits and consultations identified in Appendix E of the Final DOE EIS-0562. A borrower's failure to comply with applicable laws, authorizations, and approvals may constitute a default, upon which DOE would have the right under the loan guarantee agreement to exercise usual and customary remedies. To ensure that the borrower complies with the requirements of the loan guarantee agreement, the Loan Programs Office proactively monitors and administers all operative loan guarantee transactions for the lifetime of the loan.
                </P>
                <HD SOURCE="HD1">Signing Authority</HD>
                <P>
                    This document of the Department of Energy was signed on July 26, 2024, by Jigar Shah, Director, Loan Programs Office, 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 July 31, 2024.</DATED>
                    <NAME>Treena V. Garrett,</NAME>
                    <TITLE>Federal Register Liaison Officer, U.S. Department of Energy.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17218 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6450-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF ENERGY</AGENCY>
                <SUBJECT>Agency Information Collection Extension</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>U.S. Department of Energy.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of request for comments.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Department of Energy (DOE) invites public comment on a proposed collection of information titled Voluntary Carbon Dioxide Removal (CDR) Purchase Disclosures, which DOE is developing for submission to the Office of Management and Budget (OMB) pursuant to the Paperwork Reduction Act of 1995.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Comments regarding this proposed information collection must be received on or before September 4, 2024. If you anticipate that you will be submitting comments but find it difficult to do so within the period of time allowed by this notice, please advise the DOE Desk Officer at OMB of your intention to make a submission as soon as possible. The Desk Officer may be telephoned at (202) 395-4718.</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 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>
                        Questions may be directed to Rory Jacobson, Division Director for Carbon Dioxide Removal, Forrestal Building Rm. 4G-036, U.S. Department of Energy, 1000 Independence Ave. SW, Washington, DC 20585; or by telephone at (202) 585-1650; or by email at 
                        <E T="03">rory.jacobson@hq.doe.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P/>
                <P>
                    <E T="03">Comments are invited on:</E>
                     (a) Whether the extended collection of information is necessary for the proper performance 
                    <PRTPAGE P="63427"/>
                    of the functions of the agency, including whether the information shall have practical utility; (b) the accuracy of the agency's estimate of the burden of the proposed 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 information on respondents, including through the use of automated collection techniques or other forms of information technology.
                </P>
                <P>This information collection request contains:</P>
                <P>
                    (1) 
                    <E T="03">OMB No.:</E>
                     1910-NEW;
                </P>
                <P>
                    (2) 
                    <E T="03">Information Collection Request Title:</E>
                     Voluntary Carbon Dioxide Removal (CDR) Purchase Disclosures;
                </P>
                <P>
                    (3) 
                    <E T="03">Type of Request:</E>
                     New collection (Request for OMB control number);
                </P>
                <P>
                    (4) 
                    <E T="03">Purpose:</E>
                     DOE seeks information about purchases or pledges to purchase CDR services by organizations buying or facilitating these services. DOE will use information collected to administer the Voluntary CDR Purchasing Challenge and other potential future programs. Responses are voluntary but required to participate in the Voluntary CDR Purchasing Challenge and other potential future programs. DOE intends to publish some information collected to administer the Challenge and improve CDR market transparency. Respondents may be U.S. or international private or public sector organizations involved in CDR transactions.
                </P>
                <P>
                    (5) 
                    <E T="03">Annual Estimated Number of Respondents:</E>
                     174;
                </P>
                <P>
                    (6) 
                    <E T="03">Annual Estimated Number of Total Responses:</E>
                     1,138;
                </P>
                <P>
                    (7) 
                    <E T="03">Annual Estimated Number of Burden Hours:</E>
                     2,554;
                </P>
                <P>
                    (8) 
                    <E T="03">Annual Estimated Reporting and Recordkeeping Cost Burden:</E>
                     $236,784.
                </P>
                <HD SOURCE="HD1">Statutory Authority</HD>
                <P>Energy Policy Act of 2005, section 969D, 42 U.S.C. 16298d; Infrastructure Investment and Jobs Act, Public Law 117-58, section 41005 (2021).</P>
                <HD SOURCE="HD1">Signing Authority</HD>
                <P>
                    This document of the Department of Energy was signed on July 22, 2024, by Brad Crabtree, Assistant Secretary, Office of Fossil Energy and Carbon Management, 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 July 31, 2024.</DATED>
                    <NAME>Treena V. Garrett,</NAME>
                    <TITLE>Federal Register Liaison Officer, U.S. Department of Energy.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17217 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6450-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF ENERGY</AGENCY>
                <SUBJECT>Agency Information Collection Extension</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>U.S. Department of Energy.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of request for comments.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Department of Energy (DOE) invites public comment on a proposed collection of information that DOE is developing for submission to the Office of Management and Budget (OMB) pursuant to the Paperwork Reduction Act of 1995.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Comments regarding this proposed information collection must be received on or before September 4, 2024. If you anticipate that you will be submitting comments but find it difficult to do so within the period of time allowed by this notice, please advise the DOE Desk Officer at OMB of your intention to make a submission as soon as possible. The Desk Officer may be telephoned at (202) 395-4718.</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 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>
                        Ken Hunt, Chief Privacy Officer, U.S. Department of Energy, 19901 Germantown Road, Rm. G-302, Germantown, MD 20874 or by telephone at (301) 903-3880 or by facsimile at (301) 903-7738, or by email at 
                        <E T="03">privacyactoffice@doe.gov, https://www.energy.gov/cio/office-chief-information-officer/services/guidance/privacy-program/submitting-privacy-act.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>Comments are invited on: (a) Whether the extended collection of information is necessary for the proper performance of the functions of the agency, including whether the information shall have practical utility; (b) the accuracy of the agency's estimate of the burden of the proposed 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 information on respondents, including through the use of automated collection techniques or other forms of information technology.</P>
                <P>This information collection request contains:</P>
                <P>
                    (1) 
                    <E T="03">OMB No.:</E>
                     1910-1700;
                </P>
                <P>
                    (2) 
                    <E T="03">Information Collection Request Titled:</E>
                     Privacy Act Administration;
                </P>
                <P>
                    (3) 
                    <E T="03">Type of Review:</E>
                     Extension;
                </P>
                <P>
                    (4) 
                    <E T="03">Purpose:</E>
                     The Privacy Act Information Request form aids DOE's processing of Privacy Act requests submitted by an individual or an authorized representative, wherein he or she requests records that the government may maintain pertaining to that individual. The DOE's use of its form continues to contribute to DOE's Privacy Act processes, including, but not limited to, providing for faster processing of Privacy Act Information requests by asking individuals or their authorized representatives for pertinent information needed for records retrieval;
                </P>
                <P>
                    (5) 
                    <E T="03">Annual Estimated Number of Respondents:</E>
                     390;
                </P>
                <P>
                    (6) 
                    <E T="03">Annual Estimated Number of Total Responses:</E>
                     390;
                </P>
                <P>
                    (7) 
                    <E T="03">Annual Estimated Number of Burden Hours:</E>
                     130;
                </P>
                <P>
                    (8) 
                    <E T="03">Annual Estimated Reporting and Recordkeeping Cost Burden:</E>
                     $14,079.
                </P>
                <HD SOURCE="HD1">Statutory Authority</HD>
                <P>
                    The Privacy Act of 1974, 5 U.S.C. 552a; Department of Energy, Records Maintained on Individuals (Privacy Act), 10 CFR part 1008; 42 U.S.C. 7101 
                    <E T="03">et seq.;</E>
                     50 U.S.C. 2401 
                    <E T="03">et seq.,</E>
                     and DOE Order 206.1.
                </P>
                <HD SOURCE="HD1">Signing Authority</HD>
                <P>
                    This document of the U.S. Department of Energy was signed on July 29, 2024, by Ann Dunkin, Chief Information Officer, 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 
                    <PRTPAGE P="63428"/>
                    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 July 31, 2024.</DATED>
                    <NAME>Treena V. Garrett,</NAME>
                    <TITLE>Federal Register Liaison Officer, U.S. Department of Energy.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17216 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6450-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF ENERGY</AGENCY>
                <SUBJECT>Industrial Technology Innovation Advisory Committee</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>Notice of open meeting.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>
                        This notice announces an open virtual meeting of the Industrial Technology Innovation Advisory Committee (ITIAC). The Federal Advisory Committee Act requires that public notice of this meeting be announced in the 
                        <E T="04">Federal Register</E>
                        .
                    </P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Wednesday, August 28, 2024: 2 p.m.-4 p.m. EDT.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        This two-hour meeting will be held virtually for ITIAC members and for members of the public. The ITIAC website will contain announcements about the meeting, including instructions for registering to attend: 
                        <E T="03">https://www.energy.gov/eere/iedo/industrial-technology-innovation-advisory-committee.</E>
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Dr. Zachary Pritchard, Industrial Efficiency and Decarbonization Office, U.S. Department of Energy, Washington, DC 20585; Telephone: (202) 246-4145 or Email: 
                        <E T="03">ITIAC@ee.doe.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P/>
                <P>
                    <E T="03">Purpose of the Committee:</E>
                     The Industrial Technology Innovation Advisory Committee (Committee) was established pursuant to the Energy Independence and Security Act (EISA) of 2007 as amended by Public Law 116-260, and in accordance with the provisions of the Federal Advisory Committee Act (FACA), as amended, 5 U.S.C. 10. The Committee is established to advise the Secretary of Energy (Secretary) with respect to the Industrial Emissions Reductions Technology Development Program (the program) by identifying and evaluating any technologies being developed by the private sector relating to the focus areas described in section 454(c) of the EISA; identifying technology gaps in the private sector or other Federal agencies in those focus areas, and making recommendations on how to address those gaps; surveying and analyzing factors that prevent the adoption of emissions reduction technologies by the private sector; and recommending technology screening criteria for technology developed under the program to encourage adoption of the technology by the private sector.
                </P>
                <P>
                    <E T="03">Purpose of Meeting:</E>
                     ITIAC will hold this meeting to receive a briefing from the U.S. Department of Energy's Industrial Efficiency and Decarbonization Office (IEDO) on the forthcoming vision study, 
                    <E T="03">Pathways for U.S. Industrial Transformations: Unlocking American Innovation,</E>
                     to help identify cost-effective and industry-specific strategic pathways to achieve a thriving U.S. industrial sector with net-zero greenhouse gas emissions by 2050. This briefing will inform ITIAC's ongoing work toward developing a strategic plan on how to achieve the goals of the Industrial Emissions Reductions Technology Development Program.
                </P>
                <P>
                    <E T="03">Tentative Agenda:</E>
                </P>
                <FP SOURCE="FP-1">• Call to Order, Introductions, Review of the Agenda</FP>
                <FP SOURCE="FP-1">• Vision Study Overview</FP>
                <FP SOURCE="FP-1">• Q&amp;A and Discussion</FP>
                <FP SOURCE="FP-1">• Public Comment Period and Closing Remarks</FP>
                <FP SOURCE="FP-1">• Adjourn</FP>
                <P>
                    All attendees are requested to register in advance. The ITIAC website will be updated with instructions and links to register for the meeting: 
                    <E T="03">https://www.energy.gov/eere/iedo/industrial-technology-innovation-advisory-committee.</E>
                </P>
                <P>
                    <E T="03">Public Participation:</E>
                     The ITIAC welcomes the attendance of the public at its meetings. Individuals who wish to offer public comments at the ITIAC meeting may do so, but must register in advance by 5:00 p.m. Eastern time on Monday, August 26th, by sending a written request identified by “ITIAC August 2024 Meeting,” to Dr. Zachary Pritchard at 
                    <E T="03">ITIAC@ee.doe.gov.</E>
                     Approximately 15 minutes will be reserved for public comments. Time allotted per speaker will depend on the number who wish to speak but is not expected to exceed three minutes. Anyone who is not able to attend the meeting, or for whom the allotted public comments time is insufficient to address pertinent issues with the ITIAC, is invited to send a written statement identified by “ITIAC August 2024 Meeting—Written Statement,” to Dr. Zachary Pritchard at 
                    <E T="03">ITIAC@ee.doe.gov.</E>
                </P>
                <P>
                    <E T="03">Minutes:</E>
                     Minutes will be posted on the ITIAC website: 
                    <E T="03">https://www.energy.gov/eere/iedo/industrial-technology-innovation-advisory-committee.</E>
                     They can also be obtained by contacting 
                    <E T="03">ITIAC@ee.doe.gov.</E>
                </P>
                <P>
                    <E T="03">Signing Authority:</E>
                     This document of the Department of Energy was signed on July 31, 2024, by David Borak, Committee Management Officer, 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 July 31, 2024.</DATED>
                    <NAME>Treena V. Garrett,</NAME>
                    <TITLE>Federal Register Liaison Officer, U.S. Department of Energy.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17241 Filed 8-2-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>
                <SUBJECT>Combined Notice of Filings #1</SUBJECT>
                <P>Take notice that the Commission received the following exempt wholesale generator filings:</P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     EG24-236-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Lockhart CL ESS I, LLC.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Lockhart CL ESS I, LLC submits Notice of Self-Certification of Exempt Wholesale Generator Status.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     7/30/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240730-5102.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 8/20/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     EG24-237-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Lockhart CL ESS II, LLC.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Lockhart CL ESS II, LLC submits Notice of Self-Certification of Exempt Wholesale Generator Status.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     7/30/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240730-5116.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 8/20/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     EG24-238-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Mordor ES1 LLC.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Mordor ES1 LLC submits Notice of Self-Certification of Exempt Wholesale Generator Status.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     7/30/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240730-5125.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 8/20/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     EG24-239-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Mordor ES2 LLC.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Mordor ES2 LLC submits Notice of Self-Certification of Exempt Wholesale Generator Status.
                    <PRTPAGE P="63429"/>
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     7/30/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240730-5126.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 8/20/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     EG24-240-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Gravel Pit Solar III, LLC.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Gravel Pit Solar III, LLC submits Notice of Self-Certification of Exempt Wholesale Generator Status.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     7/30/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240730-5134.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 8/20/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     EG24-241-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Gravel Pit Solar IV, LLC.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Gravel Pit Solar IV, LLC submits Notice of Self-Certification of Exempt Wholesale Generator Status.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     7/30/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240730-5135.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 8/20/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     EG24-242-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Gravel Pit Solar, LLC.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Gravel Pit Solar, LLC submits Notice of Self-Certification of Exempt Wholesale Generator Status.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     7/30/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240730-5136.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 8/20/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     EG24-243-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     DESRI Gravel Pit Construction Borrower, L.L.C.
                </P>
                <P>
                    <E T="03">Description:</E>
                     DESRI Gravel Pit Construction Borrower, L.L.C. submits Notice of Self-Certification of Exempt Wholesale Generator Status.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     7/30/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240730-5137.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 8/20/24.
                </P>
                <P>Take notice that the Commission received the following electric rate filings:</P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER10-3299-016; ER10-3286-017.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Millennium Power Partners, L.P., New Athens Generating Company, LLC.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Notice of Non-Material Change in Status of New Athens Generating Company, LLC et al.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     7/29/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240729-5190.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 8/19/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER18-2511-009.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     NorthWestern Corporation.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Notice of Change in Status of NorthWestern Corporation.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     7/29/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240729-5192.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 8/19/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER24-2617-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Escalante Solar, LLC.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Compliance filing: Escalante Solar LLC Change in Status Filing to be effective 9/30/2024.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     7/30/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240730-5034.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 8/20/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER24-2618-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     AL Solar D, LLC.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Compliance filing: AL Solar D LLC Change in Status Filing to be effective 9/30/2024.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     7/30/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240730-5036.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 8/20/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER24-2619-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     FL Solar 5, LLC.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Compliance filing: FL Solar 5 LLC Change in Status Filing to be effective 9/30/2024.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     7/30/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240730-5037.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 8/20/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER24-2620-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     MS Solar 5, LLC.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Compliance filing: MS Solar 5 LLC Change in Status Filing to be effective 9/30/2024.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     7/30/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240730-5038.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 8/20/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER24-2621-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     MS Solar 6, LLC.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Compliance filing: MS Solar 6 Change in Status Filing to be effective 9/30/2024.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     7/30/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240730-5039.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 8/20/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER24-2622-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Southwest Power Pool, Inc.
                </P>
                <P>
                    <E T="03">Description:</E>
                     § 205(d) Rate Filing: Revisions to Attachment J to Update the 125% Peak Load Criterion for Safe Harbor to be effective 9/30/2024.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     7/30/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240730-5050.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 8/20/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER24-2623-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     New England Power Pool Participants Committee.
                </P>
                <P>
                    <E T="03">Description:</E>
                     § 205(d) Rate Filing: Aug 2024 Membership Filing to be effective 8/1/2024.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     7/30/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240730-5108.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 8/20/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER24-2624-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Mordor ES1 LLC.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Baseline eTariff Filing: Application for Market Based Authority to be effective 7/31/2024.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     7/30/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240730-5109.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 8/20/24.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER24-2625-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Mordor ES2 LLC.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Baseline eTariff Filing: Application for Market Based Rate Authority to be effective 7/31/2024.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     7/30/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240730-5112.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 8/20/24.
                </P>
                <P>
                    The filings are accessible in the Commission's eLibrary system (
                    <E T="03">https://elibrary.ferc.gov/idmws/search/fercgensearch.asp</E>
                    ) by querying the docket number.
                </P>
                <P>Any person desiring to intervene, to protest, or to answer a complaint in any of the above proceedings must file in accordance with Rules 211, 214, or 206 of the Commission's Regulations (18 CFR 385.211, 385.214, or 385.206) on or before 5:00 p.m. Eastern time on the specified comment date. Protests may be considered, but intervention is necessary to become a party to the proceeding.</P>
                <P>
                    eFiling is encouraged. More detailed information relating to filing requirements, interventions, protests, service, and qualifying facilities filings can be found at: 
                    <E T="03">http://www.ferc.gov/docs-filing/efiling/filing-req.pdf.</E>
                     For other information, call (866) 208-3676 (toll free). For TTY, call (202) 502-8659.
                </P>
                <P>
                    The Commission's Office of Public Participation (OPP) supports meaningful public engagement and participation in Commission proceedings. OPP can help members of the public, including landowners, environmental justice communities, Tribal members and others, access publicly available information and navigate Commission processes. For public inquiries and assistance with making filings such as interventions, comments, or requests for rehearing, the public is encouraged to contact OPP at (202) 502-6595 or 
                    <E T="03">OPP@ferc.gov.</E>
                </P>
                <SIG>
                    <DATED>Dated: July 30, 2024.</DATED>
                    <NAME>Debbie-Anne A. Reese,</NAME>
                    <TITLE>Acting Secretary.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2024-17197 Filed 8-2-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. RM98-1-000]</DEPDOC>
                <SUBJECT>Records Governing Off-the-Record Communications; Public Notice</SUBJECT>
                <P>This constitutes notice, in accordance with 18 CFR 385.2201(b), of the receipt of prohibited and exempt off-the-record communications.</P>
                <P>
                    Order No. 607 (64 FR 51222, September 22, 1999) requires Commission decisional employees, who make or receive a prohibited or exempt off-the-record communication relevant to the merits of a contested proceeding, to deliver to the Secretary of the Commission, a copy of the communication, if written, or a 
                    <PRTPAGE P="63430"/>
                    summary of the substance of any oral communication.
                </P>
                <P>Prohibited communications are included in a public, non-decisional file associated with, but not a part of, the decisional record of the proceeding. Unless the Commission determines that the prohibited communication and any responses thereto should become a part of the decisional record, the prohibited off-the-record communication will not be considered by the Commission in reaching its decision. Parties to a proceeding may seek the opportunity to respond to any facts or contentions made in a prohibited off-the-record communication and may request that the Commission place the prohibited communication and responses thereto in the decisional record. The Commission will grant such a request only when it determines that fairness so requires. Any person identified below as having made a prohibited off-the-record communication shall serve the document on all parties listed on the official service list for the applicable proceeding in accordance with Rule 2010, 18 CFR 385.2010.</P>
                <P>Exempt off-the-record communications are included in the decisional record of the proceeding, unless the communication was with a cooperating agency as described by 40 CFR 1501.6, made under 18 CFR 385.2201(e) (1) (v).</P>
                <P>
                    The following is a list of off-the-record communications recently received by the Secretary of the Commission. Each filing may be viewed on the Commission's website at 
                    <E T="03">http://www.ferc.gov</E>
                     using the eLibrary link. Enter the docket number, excluding the last three digits, in the docket number field to access the document. For assistance, please contact FERC Online Support at 
                    <E T="03">FERCOnlineSupport@ferc.gov</E>
                     or toll free at (866) 208-3676, or for TTY, contact (202) 502-8659.
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         Emailed comments of David Rosenstein and 5 other individuals.
                    </P>
                    <P>
                        <SU>2</SU>
                         Emailed comments of Ann Dorsey and 4 other individuals.
                    </P>
                    <P>
                        <SU>3</SU>
                         Emailed comments of Bob Bingaman and 6 other individuals.
                    </P>
                    <P>
                        <SU>4</SU>
                         Correspondence from Advisory Council on Historic Preservation.
                    </P>
                    <P>
                        <SU>5</SU>
                         Emailed comments of Joseph Mondello and Jessica Grim.
                    </P>
                    <P>
                        <SU>6</SU>
                         Emailed comments Nadine Goodwin.
                    </P>
                    <P>
                        <SU>7</SU>
                         U.S. Representative Alexandria Ocasio-Cortez, Nydia Velasquez, and Raul Grijalva.
                    </P>
                    <P>
                        <SU>8</SU>
                         Memo of telephone communication of 7/15 and email communication of 7/16 with Virginia Department of Environmental Quality.
                    </P>
                    <P>
                        <SU>9</SU>
                         Email correspondence with Steven Murphy of Brookfield Renewable regarding the West Canada Creek water quality study report.
                    </P>
                </FTNT>
                <GPOTABLE COLS="3" OPTS="L2,tp0,i1" CDEF="s75,15,r100">
                    <TTITLE> </TTITLE>
                    <BOXHD>
                        <CHED H="1">Docket Nos.</CHED>
                        <CHED H="1">File date</CHED>
                        <CHED H="1">Presenter or requester</CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="22">Prohibited:</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">1. CP19-502-000</ENT>
                        <ENT>7-23-2024</ENT>
                        <ENT>
                            FERC Staff.
                            <SU>1</SU>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">2. CP19-502-000</ENT>
                        <ENT>7-24-2024</ENT>
                        <ENT>
                            FERC Staff.
                            <SU>2</SU>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">3. CP19-502-000</ENT>
                        <ENT>7-25-2024</ENT>
                        <ENT>
                            FERC Staff.
                            <SU>3</SU>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">4. P-14861-002</ENT>
                        <ENT>7-26-2024</ENT>
                        <ENT>
                            FERC Staff.
                            <SU>4</SU>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">5. CP19-502-000</ENT>
                        <ENT>7-29-2024</ENT>
                        <ENT>
                            FERC Staff.
                            <SU>5</SU>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">6. CP19-502-000</ENT>
                        <ENT>7-30-2024</ENT>
                        <ENT>
                            FERC Staff.
                            <SU>6</SU>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22">Exempt:</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">1. CP17-458-000</ENT>
                        <ENT>7-16-2024</ENT>
                        <ENT>U.S. Representative Tom Cole.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">2. CP21-496-000</ENT>
                        <ENT>7-22-2024</ENT>
                        <ENT>
                            U.S. Congress.
                            <SU>7</SU>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">3. P-5596-020</ENT>
                        <ENT>7-22-2024</ENT>
                        <ENT>
                            FERC Staff.
                            <SU>8</SU>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">4. P-2701-000</ENT>
                        <ENT>7-29-2024</ENT>
                        <ENT>
                            FERC Staff.
                            <SU>9</SU>
                        </ENT>
                    </ROW>
                </GPOTABLE>
                <SIG>
                    <DATED>Dated: July 30, 2024.</DATED>
                    <NAME>Debbie-Anne A. Reese,</NAME>
                    <TITLE>Acting Secretary.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2024-17195 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6717-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF ENERGY</AGENCY>
                <SUBAGY>Federal Energy Regulatory Commission</SUBAGY>
                <DEPDOC>[Project No. 2561-057]</DEPDOC>
                <SUBJECT>Sho-Me Power Electric Cooperative; Notice of Availability of Environmental Assessment</SUBJECT>
                <P>In accordance with the National Environmental Policy Act of 1969 and the Federal Energy Regulatory Commission's (Commission or FERC) regulations, 18 CFR part 380, Commission staff reviewed Sho-Me Power Electric Cooperative's (Sho-Me) application for surrender of license for the Niangua Hydroelectric Project No. 2561 and have prepared an Environmental Assessment (EA) for the proposed surrender. The licensee proposes to leave the facilities in place, including the project dam, power tunnel, powerhouse, and associated facilities. The power canal would be drained and sealed at both ends and the project would be disconnected from the power grid. No ground disturbing activities are proposed with surrender of the project license. The project is located on the Niangua River in Camden County, Missouri.</P>
                <P>The EA contains Commission staff's analysis of the potential environmental effects of surrendering the license and concludes that the proposed surrender, with appropriate environmental protective measures, would not constitute a major Federal action that would significantly affect the quality of the human environment.</P>
                <P>
                    The EA may be viewed on the Commission's website at 
                    <E T="03">http://www.ferc.gov</E>
                     using the “elibrary” link. Enter the docket number (P-2561) in the docket number field to access the document. For assistance, contact FERC Online Support at 
                    <E T="03">FERCOnlineSupport@ferc.gov</E>
                     or toll-free at 1-866-208-3676, or for TTY, (202) 502-8659.
                </P>
                <P>
                    You may also register online at 
                    <E T="03">http://www.ferc.gov/docs-filing/esubscription.asp</E>
                     to be notified via email of new filings and issuances related to this or other pending projects. For assistance, contact FERC Online Support.
                </P>
                <P>All comments must be filed by August 29, 2024.</P>
                <P>
                    The Commission strongly encourages electronic filing. Please file comments using the Commission's eFiling system at 
                    <E T="03">http://www.ferc.gov/docs-filing/efiling.asp.</E>
                     Commenters can submit brief comments up to 6,000 characters, without prior registration, using the eComment system at 
                    <E T="03">http://www.ferc.gov/docs-filing/ecomment.asp.</E>
                     For assistance, please contact FERC Online Support. In lieu of electronic filing, you may submit a paper copy. Submissions sent via the U.S. Postal Service must be addressed to: Debbie-Anne Reese, Acting Secretary, Federal Energy Regulatory Commission, 888 First Street NE, Room 1A, Washington, DC 20426. 
                    <PRTPAGE P="63431"/>
                    Submissions sent via any other carrier must be addressed to: Debbie-Anne Reese, Acting Secretary, Federal Energy Regulatory Commission, 12225 Wilkins Avenue, Rockville, Maryland 20852. The first page of any filing should include docket number P-2561-057.
                </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>
                    For further information, contact Rebecca Martin at 202-502-6012 or 
                    <E T="03">Rebecca.Martin@ferc.gov.</E>
                </P>
                <SIG>
                    <DATED>Dated: July 30, 2024.</DATED>
                    <NAME>Debbie-Anne A. Reese,</NAME>
                    <TITLE>Acting Secretary.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2024-17199 Filed 8-2-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 in Existing Proceedings</HD>
                <P>
                    <E T="03">Docket Numbers:</E>
                     RP24-780-003.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Maritimes &amp; Northeast Pipeline, L.L.C.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Compliance filing: MNUS Rate Case Compliance Filing—RP24-780 to be effective 9/1/2024.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     7/29/24.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20240729-5100.
                </P>
                <P>
                    <E T="03">Comment Date:</E>
                     5 p.m. ET 8/12/24.
                </P>
                <P>Any person desiring to protest in any the above proceedings must file in accordance with Rule 211 of the Commission's Regulations (18 CFR 385.211) on or before 5:00 p.m. Eastern time on the specified comment date.</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">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.</P>
                <P>
                    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: July 30, 2024.</DATED>
                    <NAME>Debbie-Anne A. Reese,</NAME>
                    <TITLE>Acting Secretary.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2024-17196 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6717-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">EXPORT-IMPORT BANK</AGENCY>
                <SUBJECT>Application for Final Commitment for a Long-Term Loan or Financial Guarantee in Excess of $100 Million: AP089431XX</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Export-Import Bank of the United States.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>This Notice is to inform the public the Export-Import Bank of the United States (“EXIM”) has received an application for final commitment for a long-term loan or financial guarantee in excess of $100 million. Comments received within the comment period specified below will be presented to the EXIM Board of Directors prior to final action on this Transaction.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Comments must be received on or before August 30, 2024 to be assured of consideration before final consideration of the transaction by the Board of Directors of EXIM.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Comments may be submitted through 
                        <E T="03">Regulations.gov</E>
                         at 
                        <E T="03">WWW.REGULATIONS.GOV.</E>
                         To submit a comment, enter AP089431XX under the heading “Enter Keyword or ID” and select Search. Follow the instructions provided at the Submit a Comment screen. Please include your name, company name (if any) and AP089431XX on any attached document.
                    </P>
                </ADD>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P/>
                <P>
                    <E T="03">Reference:</E>
                     AP089431XX.
                </P>
                <P>
                    <E T="03">Purpose and Use:</E>
                </P>
                <P>
                    <E T="03">Brief description of the purpose of the transaction:</E>
                     Support of the export of U.S. manufactured goods and services.
                </P>
                <P>
                    <E T="03">Brief non-proprietary description of the anticipated use of the items being exported:</E>
                     To be used as core processing technology for a petrochemical complex to be built in Johor, Malaysia that will produce an array of aromatics, as well as jet fuel and diesel.
                </P>
                <P>
                    <E T="03">Parties:</E>
                </P>
                <P>
                    <E T="03">Principal Supplier:</E>
                     UOP Honeywell.
                </P>
                <P>
                    <E T="03">Obligor:</E>
                     Pengerang Energy Complex Sdn Bhd (Malaysia).
                </P>
                <P>
                    <E T="03">Guarantor(s):</E>
                     None.
                </P>
                <P>
                    <E T="03">Description of Items Being Exported:</E>
                     Honeywell UOP technology, engineering design services, licensing, equipment, product, and startup services.
                </P>
                <P>
                    <E T="03">Information on Decision:</E>
                     Information on the final decision for this transaction will be available in the “Summary Minutes of Meetings of Board of Directors” on 
                    <E T="03">https://www.exim.gov/news/meeting-minutes.</E>
                </P>
                <P>
                    <E T="03">Confidential Information:</E>
                     Please note that this notice does not include confidential or proprietary business information; information which, if disclosed, would violate the Trade Secrets Act; or information which would jeopardize jobs in the United States by supplying information that competitors could use to compete with companies in the United States.
                </P>
                <P>
                    <E T="03">Authority:</E>
                     Section 3(c)(10) of the Export-Import Bank Act of 1945, as amended (12 U.S.C. 635a(c)(10)).
                </P>
                <SIG>
                    <NAME>Diedre Hodge,</NAME>
                    <TITLE>Assistant Corporate Secretary.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17137 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6690-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">FEDERAL COMMUNICATIONS COMMISSION</AGENCY>
                <DEPDOC>[OMB 3060-0719; FR ID 236042]</DEPDOC>
                <SUBJECT>Information Collection Being Reviewed by the Federal Communications Commission</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Federal Communications Commission.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice and request for comments.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>
                        As part of its continuing effort to reduce paperwork burdens, and as required by the Paperwork Reduction Act (PRA) of 1995, the Federal Communications Commission (FCC or the Commission) invites the general public and other Federal agencies to take this opportunity to comment on the following information collection. Comments are requested concerning: 
                        <PRTPAGE P="63432"/>
                        whether the proposed collection of information is necessary for the proper performance of the functions of the Commission, including whether the information shall have practical utility; the accuracy of the Commission's burden estimate; ways to enhance the quality, utility, and clarity of the information collected; ways to minimize the burden of the collection of information on the respondents, including the use of automated collection techniques or other forms of information technology; and ways to further reduce the information collection burden on small business concerns with fewer than 25 employees.
                    </P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Written PRA comments should be submitted on or before October 4, 2024. If you anticipate that you will be submitting comments, but find it difficult to do so within the period of time allowed by this notice, you should advise the contact listed below as soon as possible.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Direct all PRA comments to Nicole Ongele, FCC, via email 
                        <E T="03">PRA@fcc.gov</E>
                         and to 
                        <E T="03">nicole.ongele@fcc.gov.</E>
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>For additional information about the information collection, contact Nicole Ongele, (202) 418-2991.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>The FCC may not conduct or sponsor a collection of information unless it displays a currently valid control number. No person shall be subject to any penalty for failing to comply with a collection of information subject to the PRA that does not display a valid Office of Management and Budget (OMB) control number.</P>
                <P>
                    <E T="03">OMB Control Number:</E>
                     3060-0719.
                </P>
                <P>
                    <E T="03">Title:</E>
                     Quarterly Report of Local Exchange Carriers Listing Payphone Automatic Number Identifications (ANIs).
                </P>
                <P>
                    <E T="03">Form Number:</E>
                     N/A.
                </P>
                <P>
                    <E T="03">Type of Review:</E>
                     Extension of a currently approved collection.
                </P>
                <P>
                    <E T="03">Respondents:</E>
                     Business or other for-profit entities.
                </P>
                <P>
                    <E T="03">Number of Respondents and Responses:</E>
                     400 respondents; 1,600 responses.
                </P>
                <P>
                    <E T="03">Estimated Time per Response:</E>
                     3.5 hours (8 hours for the initial submission; 2 hours per subsequent submission, for an average of 3.5 hours per response).
                </P>
                <P>
                    <E T="03">Frequency of Response:</E>
                     Quarterly reporting requirement, recordkeeping requirement, and third party disclosure requirement.
                </P>
                <P>
                    <E T="03">Obligation to Respond:</E>
                     Required to obtain or retain benefits. Statutory authority for this information collection is contained in 47 U.S.C. 151, 154, 201-205, 215, 218, 219, 220, 226 and 276 of the Communications Act of 1934, as amended.
                </P>
                <P>
                    <E T="03">Total Annual Burden:</E>
                     5,600 hours.
                </P>
                <P>
                    <E T="03">Total Annual Cost:</E>
                     No cost.
                </P>
                <P>
                    <E T="03">Needs and Uses:</E>
                     The Commission adopted rules and policies governing the payphone industry under section 276(b)(1)(A) of the Telecommunications Act of 1996 (the Act) and established “a per call compensation plan to ensure that all payphone service providers are fairly compensated for each and every completed intrastate and interstate call.” Pursuant to this mandate, and as required by section 64.1310(d) of the Commission's rules, Local Exchange Carriers (LECs) must provide to carriers required to pay compensation pursuant to section 64.1300(a), a quarterly report listing payphone ANIs. Without provision of this report, resolution of disputed ANIs would be rendered very difficult. Carriers would not be able to discern which ANIs pertain to payphones and therefore would not be able to ascertain which dial-around calls were originated by payphones for compensation purposes. There would be no way to guard against possible fraud. Without this collection, lengthy investigations would be necessary to verify claims. The report allows carriers to determine which dial-around calls are made from payphones. The information must be provided to third parties. The requirement would be used to ensure that LECs and the carriers required to pay compensation pursuant to 47 CFR 64.1300(a) of the Commission's rules comply with their obligations under the Telecommunications Act of 1996.
                </P>
                <SIG>
                    <FP>Federal Communications Commission.</FP>
                    <NAME>Katura Jackson,</NAME>
                    <TITLE>Federal Register Liaison Officer.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17203 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6712-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">FEDERAL ELECTION COMMISSION</AGENCY>
                <SUBJECT>Sunshine Act Meetings</SUBJECT>
                <PREAMHD>
                    <HD SOURCE="HED">TIME AND DATE:</HD>
                    <P> Tuesday, August 13, 2024 at 10:00 a.m. and its continuation at the conclusion of the open meeting on August 15, 2024.</P>
                </PREAMHD>
                <PREAMHD>
                    <HD SOURCE="HED">PLACE:</HD>
                    <P> 1050 First Street NE, Washington, DC and virtual. (This meeting will be a hybrid meeting.)</P>
                </PREAMHD>
                <PREAMHD>
                    <HD SOURCE="HED">STATUS:</HD>
                    <P> This meeting will be closed to the public.</P>
                </PREAMHD>
                <PREAMHD>
                    <HD SOURCE="HED">MATTERS TO BE CONSIDERED:</HD>
                    <P> Compliance matters pursuant to 52 U.S.C. 30109.</P>
                    <P>Matters relating to internal personnel decisions, or internal rules and practices.</P>
                    <P>Information the premature disclosure of which would be likely to have a considerable adverse effect on the implementation of a proposed Commission action.</P>
                    <P>Matters concerning participation in civil actions or proceedings or arbitration.</P>
                </PREAMHD>
                <STARS/>
                <PREAMHD>
                    <HD SOURCE="HED">CONTACT PERSON FOR MORE INFORMATION: </HD>
                    <P>Judith Ingram, Press Officer, Telephone: (202) 694-1220.</P>
                </PREAMHD>
                <EXTRACT>
                    <FP>(Authority: Government in the Sunshine Act, 5 U.S.C. 552b)</FP>
                </EXTRACT>
                <SIG>
                    <NAME>Vicktoria J. Allen,</NAME>
                    <TITLE>Deputy Secretary of the Commission.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2024-17299 Filed 8-1-24; 11:15 am]</FRDOC>
            <BILCOD>BILLING CODE 6715-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">DEPARTMENT OF HEALTH AND HUMAN SERVICES</AGENCY>
                <SUBAGY>Centers for Disease Control and Prevention</SUBAGY>
                <SUBJECT>Meeting of the Healthcare Infection Control Practices Advisory Committee</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Centers for Disease Control and Prevention (CDC), Department of Health and Human Services (HHS).</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of meeting.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>In accordance with the Federal Advisory Committee Act, the Centers for Disease Control and Prevention announces the following meeting for the Healthcare Infection Control Practices Advisory Committee (HICPAC). This virtual meeting is open to the public, limited only by the number of audio and web conference lines (500 audio and web conference lines are available). Time will be available for public comment.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>The meeting will be held on August 22, 2024, from 9 a.m. to 5 p.m., EDT.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        The meeting will be webcast live via the World Wide Web. The webcast link can be found on the HICPAC website: 
                        <E T="03">https://www.cdc.gov/hicpac/meeting.html.</E>
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Sydnee Byrd, M.P.A., Committee Management Specialist, Healthcare Infection Control Practices Advisory Committee, Division of Healthcare Quality Promotion, National Center for Emerging and Zoonotic Infectious Diseases, Centers for Disease Control and Prevention, 1600 Clifton Road NE, Mailstop H16-3, Atlanta, Georgia 30329-4027. Telephone: (404) 718-8039; Email: 
                        <E T="03">hicpac@cdc.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    <PRTPAGE P="63433"/>
                </P>
                <P>
                    <E T="03">Purpose:</E>
                     The Committee is charged with providing advice and guidance to the Director, Division of Healthcare Quality Promotion (DHQP), the Director, National Center for Emerging and Zoonotic Infectious Diseases (NCEZID), the Director, CDC, and the Secretary, Department of Health and Human Services, regarding (1) the practice of healthcare infection prevention and control; (2) strategies for surveillance, prevention, and control of infections, antimicrobial resistance, and related events in settings where healthcare is provided; and (3) periodic updating of CDC guidelines and other policy statements regarding prevention of healthcare-associated infections and healthcare-related conditions.
                </P>
                <P>
                    <E T="03">Matters to be Considered:</E>
                     The agenda will include the following updates: The Healthcare Personnel Guideline Workgroup; Isolation Precautions Guideline Workgroup; Dental Unit Waterlines Guideline Update; Division of Health Quality Promotion Updates; Review of Viral Hemorrhagic Fever Update; Pathogen Reduction Guidance Introduction; NHSN Update; Recommendation Categorization Framework Update. Agenda items are subject to change.
                </P>
                <HD SOURCE="HD1">Public Participation</HD>
                <P>
                    <E T="03">Oral Public Comment:</E>
                     This meeting will include time for members of the public to make an oral comment. Priority will be given to individuals who submit a request to make an oral public comment before the meeting according to the procedures below. All persons interested in making an oral public comment at the August 22, 2024 HICPAC meeting must submit a request between July 26, 2024, and August 12, 2024, at 
                    <E T="03">https://www.cdc.gov/hicpac/meeting.html</E>
                     no later than 11:59 p.m., EDT, August 12, 2024, according to the instructions provided on the HICPAC website. If the number of persons requesting to speak is greater than can be reasonably accommodated during the scheduled time, CDC will conduct a lottery to determine the speakers for the scheduled public comment session. CDC staff will notify individuals regarding their request to speak by email by August 17, 2024.
                </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>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17220 Filed 8-2-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 Disease Control and Prevention</SUBAGY>
                <SUBJECT>Meeting of the Advisory Committee on Breast Cancer in Young Women</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Centers for Disease Control and Prevention (CDC), Department of Health and Human Services (HHS).</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of meeting.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>In accordance with the Federal Advisory Committee Act, the Centers for Disease Control and Prevention (CDC) announces the following meeting of the Advisory Committee on Breast Cancer in Young Women (ACBCYW). This meeting is open to the public, limited only by conference room space and web Conference lines (40 conference room and 60 web conference participant spaces available). Online registration is required.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>The meeting will be held on September 13, 2024, from 8:30 a.m. to 4 p.m., EDT.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        4770 Buford Highway, Atlanta, Georgia 30341, Building 106, Room 1B. All ACBCYW Meeting participants must register for the meeting online at least 5 business days in advance at 
                        <E T="03">https://www.cdc.gov/breast-cancer/php/advisory-committee/index.html.</E>
                         Please complete all the required fields and submit your registration no later than September 6, 2024. Registered participants will receive access instructions before the meeting. All visitors are required to present a valid form of picture identification issued by a state, federal or international government. As required by the Federal Property Management Regulations, all persons entering in or on Federal controlled property and their packages, briefcases, and other containers in their immediate possession are subject to being x-rayed and inspected. Federal law prohibits the knowing possession or the causing to be present of firearms, explosives and other dangerous weapons and illegal substances. Time will be available for public comment. The public is welcome to submit written comments in advance of the meeting. Comments should be submitted in writing by email to 
                        <E T="03">acbcyw@cdc.gov.</E>
                         The deadline for receipt is September 10, 2024.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Kimberly E. Smith, M.B.A., M.H.A., Designated Federal Officer, Advisory Committee on Breast Cancer in Young Women, National Center for Chronic Disease Prevention and Health Promotion, Centers for Disease Control and Prevention, 4770 Buford Highway NE, Mailstop S107-4, Atlanta, Georgia 30341. Telephone: (404) 498-0073; Fax: (770) 488-4760; Email: 
                        <E T="03">acbcyw@cdc.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P/>
                <P>
                    <E T="03">Purpose:</E>
                     The Advisory Committee provides advice and guidance to the Secretary, HHS; the Assistant Secretary for Health; and the Director, CDC, regarding the formative research, development, implementation, and evaluation of evidence-based activities designed to prevent breast cancer (particularly among those at heightened risk) and promote the early detection and support of young women who develop the disease. The advice provided by the Advisory Committee will assist in ensuring scientific quality, timeliness, utility, and dissemination of credible appropriate messages and resource materials.
                </P>
                <P>
                    <E T="03">Matters to be Considered:</E>
                     The agenda will include discussions on current topics related to breast cancer in young women. These will include Mental/Behavioral Health, Sexual Health, Genetics and Genomics, and Provider Engagement. Agenda items are subject to change as priorities dictate.
                </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>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17219 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4163-18-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <PRTPAGE P="63434"/>
                <AGENCY TYPE="S">DEPARTMENT OF HEALTH AND HUMAN SERVICES</AGENCY>
                <SUBAGY>Administration for Children and Families</SUBAGY>
                <SUBJECT>Proposed Information Collection Activity; “State SNAP Agency NDNH Matching Program Performance Report” (Office of Management Budget #0970-0464)</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Office of Child Support Services, Administration for Children and Families, U.S. Department of Health and Human Services.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Request for public comments.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Office of Child Support Services (OCSS) is requesting the federal Office of Management and Budget (OMB)approve the “State SNAP Agency NDNH Matching Program Performance Report,” with minor revisions, for an additional three years. State agencies administering their Supplemental Nutrition Assistance Program (SNAP) provide the annual performance report to OCSS in accordance with the computer matching agreement between state SNAP agencies and OCSS. The current OMB approval expires on February 28, 2025.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>
                        <E T="03">Comments due within 60 days of publication.</E>
                         In compliance with the requirements of the Paperwork Reduction Act of 1995, the Administration for Children and Families is soliciting public comment on the specific aspects of the information collection described above.
                    </P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        To submit comments and obtain copies of the proposed collection of information, email 
                        <E T="03">infocollection@acf.hhs.gov.</E>
                         Identify all requests by the title of the information collection.
                    </P>
                </ADD>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P/>
                <P>
                    <E T="03">Description:</E>
                     State agencies administering SNAP are mandated to participate in a computer matching program with OCSS. The matching program compares SNAP applicant and recipient information with employment and wage information maintained in the National Directory of New Hires (NDNH). The outcomes of the compared information help state SNAP agencies verify an individual's identity and determine a benefit eligibility. To receive NDNH information, state agencies enter into a computer matching agreement and adhere to its terms and conditions, including providing OCSS with annual performance outcomes attributable to the use of NDNH information. To fulfill OMB requirements, OCSS periodically reports performance measurements demonstrating how the use of information in the NDNH supports the OCSS strategic mission, goals, and objectives. These periodic reports include information derived from state SNAP agency annual NDNH performance reports. OCSS provides states with required performance report templates and instructions, which underwent minor language edits.
                </P>
                <P>
                    <E T="03">Respondents:</E>
                     State SNAP Agencies.
                </P>
                <GPOTABLE COLS="5" OPTS="L2,i1" CDEF="s100,12C,12C,12C,12C">
                    <TTITLE>Annual Burden Estimates</TTITLE>
                    <BOXHD>
                        <CHED H="1">Instrument</CHED>
                        <CHED H="1">
                            Total
                            <LI>number of respondents</LI>
                        </CHED>
                        <CHED H="1">
                            Annual 
                            <LI>number of</LI>
                            <LI>responses per respondent</LI>
                        </CHED>
                        <CHED H="1">
                            Average
                            <LI>burden hours</LI>
                            <LI>per response</LI>
                        </CHED>
                        <CHED H="1">
                            Total annual
                            <LI>burden hours</LI>
                        </CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">SNAP Agency Performance Reporting Tool and Instructions</ENT>
                        <ENT>53</ENT>
                        <ENT>1</ENT>
                        <ENT>0.83</ENT>
                        <ENT>43.99</ENT>
                    </ROW>
                </GPOTABLE>
                <P>
                    <E T="03">Comments:</E>
                     The Department specifically requests comments on (a) 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; (b) the accuracy of the agency's estimate of the burden of the proposed collection of information; (c) the quality, utility, and clarity of the information to be collected; and (d) ways to minimize the burden of the collection of information on respondents, including through the use of automated collection techniques or other forms of information technology. OCSS will consider comments and suggestions submitted within 60 days of this publication.
                </P>
                <P>
                    <E T="03">Authority:</E>
                     42 U.S.C. 653(j)(10); 5 U.S.C. 552a; and Public Law 111-352.
                </P>
                <SIG>
                    <TITLE>Mary C. Jones, ACF/OPRE Certifying Officer.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17148 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4184-41-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-2022-N-0621]</DEPDOC>
                <SUBJECT>Advisory Committee; Anesthetic and Analgesic Drug Products Advisory Committee; Renewal</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Food and Drug Administration, HHS.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice; renewal of Federal advisory committee.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Food and Drug Administration (FDA or the Agency) is announcing the renewal of the Anesthetic and Analgesic Drug Products Advisory Committee by the Commissioner of Food and Drugs (the Commissioner). The Commissioner has determined that it is in the public interest to renew the Anesthetic and Analgesic Drug Products Advisory Committee for an additional 2 years beyond the charter expiration date. The new charter will be in effect until the May 1, 2026, expiration date.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Authority for the Anesthetic and Analgesic Drug Products Advisory Committee will expire on May 1, 2026, unless the Commissioner formally determines that renewal is in the public interest.</P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Joyce Frimpong, Center for Drug Evaluation and Research, Food and Drug Administration, 10903 New Hampshire Ave., Bldg. 31, Rm. 2417, Silver Spring, MD 20993-0002, 301-796-7973, email: 
                        <E T="03">AADPAC@fda.hhs.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>Pursuant to 41 CFR 102-3.65 and approval by the Department of Health and Human Services and by the General Services Administration, FDA is announcing the renewal of the Anesthetic and Analgesic Drug Products Advisory Committee (the Committee). The Committee is a discretionary Federal advisory committee established to provide advice to the Commissioner. The Committee advises the Commissioner or designee in discharging responsibilities as they relate to helping to ensure safe and effective drugs for human use and, as required, any other product for which FDA has regulatory responsibility.</P>
                <P>
                    The Committee reviews and evaluates available data concerning the safety and effectiveness of marketed and 
                    <PRTPAGE P="63435"/>
                    investigational human drug products including analgesics; 
                    <E T="03">e.g.,</E>
                     abuse-deterrent opioids, novel analgesics, and issues related to opioid abuse, and those for use in anesthesiology and makes appropriate recommendations to the Commissioner of Food and Drugs.
                </P>
                <P>Pursuant to its charter, the Committee shall consist of a core of 11 voting members including the Chair. Members and the Chair are selected by the Commissioner or designee from among authorities knowledgeable in the fields of anesthesiology, analgesics (such as: abuse deterrent opioids, novel analgesics, and issues related to opioid abuse) epidemiology or statistics, and related specialties. Members will be invited to serve for overlapping terms of up to 4 years. Non-Federal members of this committee will serve as Special Government Employees or representatives. Federal members will serve as Regular Government Employees or Ex-Officios. The core of voting members may include one technically qualified member, selected by the Commissioner or designee, who is identified with consumer interests and is recommended by either a consortium of consumer-oriented organizations or other interested persons. In addition to the voting members, the Committee may include one non-voting representative member who is identified with industry interests. There may also be an alternate industry representative.</P>
                <P>The Commissioner or designee shall have the authority to select members of other scientific and technical FDA advisory committees (normally not to exceed 10 members) to serve temporarily as voting members and to designate consultants to serve temporarily as voting members when: (1) expertise is required that is not available among current voting standing members of the Committee (when additional voting members are added to the Committee to provide needed expertise, a quorum will be based on the combined total of regular and added members) or (2) to comprise a quorum when, because of unforeseen circumstances, a quorum is or will be lacking. Because of the size of the Committee and the variety in the types of issues that it will consider, FDA may, in connection with a particular committee meeting, specify a quorum that is less than a majority of the current voting members. The Agency's regulations (21 CFR 14.22(d)) authorize a committee charter to specify quorum requirements.</P>
                <P>If functioning as a medical device panel, an additional non-voting representative member of consumer interests and an additional non-voting representative member of industry interests will be included in addition to the voting members.</P>
                <P>
                    Further information regarding the most recent charter and other information can be found at 
                    <E T="03">https://www.fda.gov/advisory-committees/human-drug-advisory-committees/anesthetic-and-analgesic-drug-products-advisory-committee</E>
                     or by contacting the Designated Federal Officer (see 
                    <E T="02">FOR FURTHER INFORMATION CONTACT</E>
                    ). In light of the fact that no change has been made to the committee name or description of duties, no amendment will be made to 21 CFR 14.100.
                </P>
                <P>
                    This notice is issued under the Federal Advisory Committee Act (5 U.S.C. 1001 
                    <E T="03">et seq.</E>
                    ). For general information related to FDA advisory committees, please visit us at 
                    <E T="03">http://www.fda.gov/AdvisoryCommittees/default.htm.</E>
                </P>
                <SIG>
                    <DATED>Dated: July 31, 2024.</DATED>
                    <NAME>Lauren K. Roth,</NAME>
                    <TITLE>Associate Commissioner for Policy.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17248 Filed 8-2-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-2022-N-0618]</DEPDOC>
                <SUBJECT>Advisory Committee; Drug Safety and Risk Management Advisory Committee; Renewal</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Food and Drug Administration, HHS.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice; renewal of Federal advisory committee.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Food and Drug Administration (FDA or the Agency) is announcing the renewal of the Drug Safety and Risk Management Advisory Committee by the Commissioner of Food and Drugs (the Commissioner). The Commissioner has determined that it is in the public interest to renew the Drug Safety and Risk Management Advisory Committee for an additional 2 years beyond the charter expiration date. The new charter will be in effect until the May 31, 2026, expiration date.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Authority for the Drug Safety and Risk Management Advisory Committee will expire on May 31, 2026, unless the Commissioner formally determines that renewal is in the public interest.</P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Moon Choi, Center for Drug Evaluation and Research, Food and Drug Administration, 10903 New Hampshire Ave., Bldg. 31, Rm. 2417, Silver Spring, MD 20993-0002, (240) 743-8319, 
                        <E T="03">DSaRM@fda.hhs.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>Pursuant to 41 CFR 102-3.65 and approval by the Department of Health and Human Services (HHS) and by the General Services Administration, FDA is announcing the renewal of the Drug Safety and Risk Management Advisory Committee (the Committee). The Committee is a discretionary Federal advisory committee established to provide advice to the Commissioner. The Committee advises the Commissioner or designee in discharging responsibilities as they relate to helping to ensure safe and effective drugs for human use and, as required, any other product for which FDA has regulatory responsibility.</P>
                <P>The Committee reviews and evaluates information on risk management, risk communication, and quantitative evaluation of spontaneous reports for drugs for human use and for any other product for which FDA has regulatory responsibility. The Committee also advises the Commissioner regarding the scientific and medical evaluation of all information gathered by HHS and the Department of Justice with regard to safety, efficacy, and abuse potential of drugs or other substances, and recommends actions to be taken by HHS with regard to the marketing, investigation, and control of such drugs or other substances.</P>
                <P>
                    Pursuant to its Charter, the Committee shall consist of a core of 11 voting members including the Chair. Members and the Chair are selected by the Commissioner or designee from among authorities knowledgeable in the fields of risk communication, risk management, drug safety, medical, behavioral, and biological sciences as they apply to risk management, and drug abuse. Members will be invited to serve for overlapping terms of up to 4 years. Non-Federal members of this committee will serve as Special Government Employees or representatives. Federal members will serve as Regular Government Employees or Ex-Officios. The core of voting members may include one technically qualified member, selected by the Commissioner or designee, who is identified with consumer interests and is recommended by either a consortium of consumer-oriented organizations or other interested persons. In addition to the voting members, the Committee may include one non-voting representative member who is identified with industry interests. There may also be an alternate industry representative.
                    <PRTPAGE P="63436"/>
                </P>
                <P>The Commissioner or designee shall have the authority to select members of other scientific and technical FDA advisory committees (normally not to exceed 10 members) to serve temporarily as voting members and to designate consultants to serve temporarily as voting members when: (1) expertise is required that is not available among current voting standing members of the Committee (when additional voting members are added to the Committee to provide needed expertise, a quorum will be based on the combined total of regular and added members), or (2) to comprise a quorum when, because of unforeseen circumstances, a quorum is or will be lacking. Because of the size of the Committee and the variety in the types of issues that it will consider, FDA may, in connection with a particular committee meeting, specify a quorum that is less than a majority of the current voting members. The Agency's regulations (21 CFR 14.22(d)) authorize a committee charter to specify quorum requirements.</P>
                <P>If functioning as a medical device panel, an additional non-voting representative member of consumer interests and an additional non-voting representative member of industry interests will be included in addition to the voting members.</P>
                <P>
                    Further information regarding the most recent charter and other information can be found at 
                    <E T="03">https://www.fda.gov/advisory-committees/human-drug-advisory-committees/drug-safety-and-risk-management-advisory-committee</E>
                     or by contacting the Designated Federal Officer (see 
                    <E T="02">FOR FURTHER INFORMATION CONTACT</E>
                    ). In light of the fact that no change has been made to the committee name or description of duties, no amendment will be made to 21 CFR 14.100.
                </P>
                <P>
                    This notice is issued under the Federal Advisory Committee Act (5 U.S.C. 1001 
                    <E T="03">et seq.</E>
                    ). For general information related to FDA advisory committees, please visit us at 
                    <E T="03">http://www.fda.gov/AdvisoryCommittees/default.htm.</E>
                </P>
                <SIG>
                    <DATED>Dated: July 31, 2024.</DATED>
                    <NAME>Lauren K. Roth,</NAME>
                    <TITLE>Associate Commissioner for Policy.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17243 Filed 8-2-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>Office of the Secretary</SUBAGY>
                <SUBJECT>Notice of Interest Rate on Overdue Debts</SUBJECT>
                <P>
                    Section 30.18 of the Department of Health and Human Services' claims collection regulations (45 CFR part 30) provides that the Secretary shall charge an annual rate of interest, which is determined and fixed by the Secretary of the Treasury after considering private consumer rates of interest on the date that the Department of Health and Human Services becomes entitled to recovery. The rate cannot be lower than the Department of Treasury's current value of funds rate or the applicable rate determined from the “Schedule of Certified Interest Rates with Range of Maturities” unless the Secretary waives interest in whole or part, or a different rate is prescribed by statute, contract, or repayment agreement. The Secretary of the Treasury may revise this rate quarterly. The Department of Health and Human Services publishes this rate in the 
                    <E T="04">Federal Register</E>
                    .
                </P>
                <P>
                    The current rate of 11
                    <FR>7/8</FR>
                    %, as fixed by the Secretary of the Treasury, is certified for the quarter ended June 30, 2024. This rate is based on the Interest Rates for Specific Legislation, “National Health Services Corps Scholarship Program (42 U.S.C. 254o(b)(1)(A))” and “National Research Service Award Program (42 U.S.C. 288(c)(4)(B)).” This interest rate will be applied to overdue debt until the Department of Health and Human Services publishes a revision.
                </P>
                <SIG>
                    <NAME>David C. Horn,</NAME>
                    <TITLE>Director, Office of Financial Policy and Reporting.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2024-17139 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4150-04-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF HEALTH AND HUMAN SERVICES</AGENCY>
                <SUBAGY>National Institutes of Health</SUBAGY>
                <SUBJECT>Submission for OMB Review; 30-Day Comment Request; The Impact of Clinical Research Training and Medical Education at the Clinical Center on Physician Careers in Academia and Clinical Research</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>In compliance with the Paperwork Reduction Act of 1995, the National Institutes of Health (NIH) has submitted to the Office of Management and Budget (OMB) a request for review and approval of the information collection listed below.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Comments regarding this information collection are best assured of having their full effect if received within 30 days of the date of this publication.</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>
                        To request more information on the proposed project or to obtain a copy of the data collection plans and instruments, contact: Tom Burklow, MD, Office of Clinical Research Training and Medical Education, NIH Clinical Center, National Institutes of Health, 10 Center Drive, Room 1N262, Bethesda, MD 20892-1158, or call non-toll-free number 301-435-8015, or Email your request, including your address to: 
                        <E T="03">tom.burklow@nih.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    This proposed information collection was previously published in the 
                    <E T="04">Federal Register</E>
                     on May 13, 2024 (89 FR 41446) and allowed 60 days for public comment. No comments were received. The purpose of this notice is to allow an additional 30 days for public comment. The Clinical Center, National Institutes of Health, may not conduct or sponsor, and the respondent is not required to respond to, an information collection that has been extended, revised, or implemented on or after October 1, 1995, unless it displays a currently valid OMB control number.
                </P>
                <P>In compliance with section 3507(a)(1)(D) of the Paperwork Reduction Act of 1995, the National Institutes of Health (NIH) has submitted to the Office of Management and Budget (OMB) a request for review and approval of the information collection listed below.</P>
                <P>
                    <E T="03">Proposed Collection:</E>
                     The Impact of Clinical Research Training and Medical Education at the Clinical Center on Physician Careers in Academia and Clinical Research, OMB #0925-0602 Expiration Date: 6/30/2024, National Institutes of Health Clinical Center (CC), National Institutes of Health (NIH).
                </P>
                <P>
                    <E T="03">Need and Use of Information Collection:</E>
                     The information collected will allow continued assessment of the value of the training provided by the Office of Clinical Research Training and 
                    <PRTPAGE P="63437"/>
                    Medical Education (OCRTME) at the NIH Clinical Center and the extent to which this training promotes (a) patient safety; (b) research productivity and independence; and (c) future career development within clinical, translational, and academic research settings. The information received from respondents is presented to, evaluated by, and incorporated into the ongoing operational improvement efforts of the Director of the Office of Clinical Research Training and Education, and the Chief Executive Officer of the NIH Clinical Center. This information will enable the ongoing operational improvement efforts of the OCRTME and its commitment to providing clinical research training and medical education of the highest quality to each trainee.
                </P>
                <P>OMB approval is requested for 3 years. There are no costs to respondents other than their time. The total estimated annualized burden hours 537.</P>
                <GPOTABLE COLS="6" OPTS="L2,i1" CDEF="s100,r50,12,12,12,12">
                    <TTITLE>Estimated Annualized Burden Hours</TTITLE>
                    <BOXHD>
                        <CHED H="1">Form name</CHED>
                        <CHED H="1">Type of respondents</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">
                            Average
                            <LI>burden per</LI>
                            <LI>response</LI>
                            <LI>(in hours)</LI>
                        </CHED>
                        <CHED H="1">
                            Total annual
                            <LI>burden hours</LI>
                        </CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">Clinical Research Training Program/Medical Research Scholars Program Alumni Survey</ENT>
                        <ENT>Physicians</ENT>
                        <ENT>800</ENT>
                        <ENT>1</ENT>
                        <ENT>20/60</ENT>
                        <ENT>267</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Graduate Medical Education Graduate Survey</ENT>
                        <ENT>Physicians</ENT>
                        <ENT>350</ENT>
                        <ENT>1</ENT>
                        <ENT>20/60</ENT>
                        <ENT>117</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Clinical Electives Program 1 Year Alumni Survey</ENT>
                        <ENT>Physicians</ENT>
                        <ENT>100</ENT>
                        <ENT>1</ENT>
                        <ENT>20/60</ENT>
                        <ENT>33</ENT>
                    </ROW>
                    <ROW RUL="n,n,s">
                        <ENT I="01">Continuing Medical Education Evaluation Survey</ENT>
                        <ENT>Physicians</ENT>
                        <ENT>720</ENT>
                        <ENT>1</ENT>
                        <ENT>10/60</ENT>
                        <ENT>120</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Total</ENT>
                        <ENT/>
                        <ENT>1,970</ENT>
                        <ENT>1,970</ENT>
                        <ENT/>
                        <ENT>537</ENT>
                    </ROW>
                </GPOTABLE>
                <SIG>
                    <NAME>Frederick D. Vorck, Jr.,</NAME>
                    <TITLE>Project Clearance Liaison, NIH Clinical Center, National Institutes of Health.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17191 Filed 8-2-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>Substance Abuse and Mental Health Services Administration</SUBAGY>
                <SUBJECT>Statement of Organization, Functions, and Delegations of Authority</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Substance Abuse and Mental Health Services Administration (SAMHSA).</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Organization, functions, and delegations of authority.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>SAMHSA has modified its organizational structure.</P>
                </SUM>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>Part M of the Substance Abuse and Mental Health Services Administration (SAMHSA) Statement of Organization, Functions, and Delegations of Authority for the Department of Health and Human Services at 71 FR 19740-19741, April 17, 2006, is amended to reflect changes of the functional statements for the Center for Substance Abuse Treatment (CSAT). This amendment reflects the addition of one new division and two branches. CSAT has taken the lead in addressing the substance use disorder (SUD) treatment needs of Americans, focusing primarily on opioid treatment, developing a crisis continuum, improving adult and adolescent substance use treatment, and increasing access to and the quality of SUD treatment and recovery services. CSAT is dedicated to collaborating with grantees and stakeholders to enhance the accessibility of innovative services and evidence-based treatment modalities through grants and technical assistance.</P>
                <P>In order to enhance administrative and operational efficiencies, CSAT proposes that each supervisor within the center should have a staff to supervisor ratio of 1 supervisor to 10 staff person or less. There is currently a twelve to one staff to supervisor ratio in the Division of Services Improvement (DSI)—with one branch having 17 staff. Managing 10 or more employees can be challenging for a first-line supervisor, who must effectively handle employee management and oversee grants and contracts. By adding the Division of Health Systems Improvement (DHSI) and two branches, Integrated Care Branch (ICB) and Opioid Treatment Branch (OTB) the staff to supervisor ratio would decrease to eight to one. Moreover, streamlined and smaller divisions/branches, with specific focus areas, will provide additional oversight and management by the second-level supervisor for these important Federal grants and contracts.</P>
                <HD SOURCE="HD1">Center for Substance Abuse Treatment</HD>
                <HD SOURCE="HD1">Division of Health Systems Improvement</HD>
                <P>The proposed DHSI will focus on equity, medications for opioid use disorder (MOUD), and the continuum of care consistent with and necessary for the achievement of goals outlined in the President's Unity Agenda and the Office of National Drug Control Policy's National Drug Control Strategy. Refining the alignment of grant portfolios by the scope and span of grants and function, subject matter areas, age group focus (adolescents versus adults), and geographic focus (community versus state) will allow for improved efficiencies and service. The two branches in DHSI will be ICB and OTB. The new division will allow for dedicated leadership focusing on opioid treatment, developing a crisis continuum, improving adult and adolescent substance use treatment, and increasing access to and the quality of SUD treatment and recovery services. The proposed new division and two new branches are better aligned based on content and goal; the major grant programs impacted by this change are described below.</P>
                <P>ICB will primairly focus on increasing access to and improving the quality of services of comprehensive, coordinated, patient-centered care across the continuum. The branch will manage the Minority AIDS Initiative (MAI) and Screening, Brief Intervention, and Referral to Treatment (SBIRT) programs both of which are authorized under the Public Health Service Act (PHSA), title V, section 509. MAI seeks to increase engagement in care for racial and ethnic underrepresented individuals with SUD and/or co-occurring substance use and mental disorders (COD) who are at risk for or living with HIV/AIDS and receive HIV/AIDS services/treatment. SBIRT is a comprehensive, integrated, public health approach to the delivery of early intervention and treatment services for persons with substance use disorders, as well as those who are at risk of developing these disorders.</P>
                <P>
                    • OTB will primarily focus on providing evidence-based 
                    <PRTPAGE P="63438"/>
                    comprehensive care to individuals with opioid use disorder (OUD), reduce harm, and effectively address the opioid crisis through service grants primarily to community-based organizations. This includes service grants that support the provision of MOUD such as methadone, buprenorphine and naltrexone which allow patients to receive treatment while maintaining their daily responsibilities and lives. Work in this branch will include engaging in community outreach and education efforts to raise awareness about the opioid epidemic, prevention strategies, and available treatment options. This is different from the work done in our state-based funding programs (State Opioid Response and Substance Use Prevention, Treatment, and Recovery Services Block Grants) which are housed in the Division of State and Community Systems (DSCS) and separate from the focus of the Division of Pharmacologic Therapies (DPT) which works with Opioid Treatment Programs to provide regulatory and provider support and does not fund opioid treatment. There is no overlap in the work of the existing divisions, DSCS and DPT, and the proposed OTB within the proposed DHSI. The OTB will manage the Medication-Assisted Treatment—Prescription Drug and Opioid Addiction (MAT-PDOA) and Targeted Capacity Expansion: Special Projects (TCE-SP) programs, both of which are authorized under section 509 of the PHSA, as amended. The purpose of MAT-PDOA is to provide resources to help expand and enhance access to MOUD. It is expected that this program will help to (1) increase access to MOUD for individuals with OUD, including individuals from diverse racial, ethnic, sexual and gender minority communities; and (2) decrease illicit opioid use and prescription opioid misuse. The purpose of TCE-SP is to implement targeted strategies for the provision of SUD or COD harm reduction, treatment, and/or recovery support services to support an under-resourced population or unmet need identified by the community.
                </P>
                <HD SOURCE="HD1">Delegations of Authority</HD>
                <P>All delegations and redelegations of authority to officers and employees of SAMHSA which were in effect immediately prior to the effective date of this reorganization shall continue to be in effect.</P>
                <P>
                    <E T="03">Authority:</E>
                     44 U.S.C. 3101.
                </P>
                <SIG>
                    <NAME>Xavier Becerra,</NAME>
                    <TITLE>Secretary of Health and Human Services. </TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17131 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF HEALTH AND HUMAN SERVICES</AGENCY>
                <SUBAGY>Substance Abuse and Mental Health Services Administration</SUBAGY>
                <SUBJECT>Agency Information Collection Activities Comment Request</SUBJECT>
                <P>Periodically, the Substance Abuse and Mental Health Services Administration (SAMHSA) will publish a summary of information collection requests under OMB review, in compliance with the Paperwork Reduction Act (44 U.S.C. Chapter 35). To request a copy of these documents, call the SAMHSA Reports Clearance Officer on (240) 276-0361.</P>
                <HD SOURCE="HD1">Proposed Project: Drug and Alcohol Warning Network (DAWN) (OMB No. 0930-0078)—Reinstatement With Change</HD>
                <P>Under the Public Health Service Act (42 U.S.C. 290aa-4), SAMHSA is authorized to collect data on the number of individuals admitted to the emergency rooms of hospitals as a result of the abuse of alcohol or other drugs. DAWN is a nationwide public health surveillance system to improve hospital emergency department (ED) monitoring of substance use-related visits. It captures data on ED visits related to recent substance use and misuse directly from the electronic health records (EHR) of participating hospitals. The new DAWN helps SAMHSA and public health professionals, clinicians, and policymakers respond effectively to the opioid and substance misuse crisis in the United States.</P>
                <P>SAMHSA is requesting OMB approval of reinstatement with change of the DAWN data collections, to include following changes:</P>
                <P>• Revise the data collection title to “Drug and Alcohol Warning Network”, replacing existing `abuse' term and including “alcohol” in the title.</P>
                <P>• Remove drug-related death investigation records review component administered by state medical examiners (MEs) and individual medical examiners/coroners (ME/Cs).</P>
                <P>• Revise data collection procedures where participating hospitals can choose the direct chart review option (at the contractor's operation center, home-based abstraction or on site at the hospital). Hospitals will also have the opportunity to select the machine learning with natural language processing (ML with NLP) option. The option for hospitals to use their own staff to abstract DAWN data as they did in the legacy DAWN is no longer offered.</P>
                <P>• Revise the hospital selection design of the ED component to a hybrid system that combines sentinel hospitals and probability-based selection of hospitals from high priority suburban/rural areas and from the remaining areas in the United States.</P>
                <P>• Change the reporting and publication schedule to further increase the timeliness of the new DAWN data availability and delivery to SAMHSA. The new DAWN data are collected on an ongoing basis and could be available to SAMHSA on demand. The new DAWN data are delivered to SAMHSA and available for analysis at a more frequent intervals than the legacy DAWN.</P>
                <P>• Propose following changes to the ED Case Report Form:</P>
                <P>○ Add “Center for Behavioral Health Statistics and Quality” to specify the center responsible for DAWN data collection.</P>
                <P>○ Revise the data collection title to “Drug and Alcohol Warning Network” from “Drug Abuse Warning Network.”</P>
                <P>○ Replace prior “Facility” data field title with “Hospital Emergency Department ID” to provide more precise description and ID number of the DAWN participating hospitals.</P>
                <P>○ Q3 “Age”: replace prior option of “less than 1 year” with two detailed options of “4 weeks (28 days) or younger” and “Between 4 weeks and one year old (&gt;4 weeks, &lt;1 year)” to enable new identification of neonatal substance issues.</P>
                <P>○ Q4 “County of Residence”: revise data field title from prior “patient's home zip code” and add more accurate description on what data to be collected and clarify the purpose of data collection. Add new “Unable to determine county” option to improve data accuracy and account for geographical variation.</P>
                <P>○ Q6 “Gender Identity” and Q7 “Sexual Orientation”: added to provide inclusive measures and to align with SAMHSA's efforts in enhancing behavioral health equities among diverse populations.</P>
                <P>○ Q8 “Ethnicity” and Q9 “Race”: revise prior data field “Race/Ethnicity” to align with OMB 1997 Standards for Maintaining, Collecting, And Presenting Federal Data on Race and Ethnicity (Statistical Policy Directive No. 15) and to improve data accuracy and comprehensiveness.</P>
                <P>
                    ○ Q10 “Case Description”: replace the word “drug(s)” with “substance(s)” to clarify that the DAWN collects data on all substances including alcohol. Add new instruction language of “Do not include information that could identify the patient or hospital” to provide clear instruction and specify the 
                    <PRTPAGE P="63439"/>
                    importance of patient and hospital privacy protection.
                </P>
                <P>○ Q11 “Substance(s) Involved and Route of Administration”: add two new options of “transdermal” and “vaped” to improve the comprehensiveness of the list on how substance is administered by the patient. Remove “Mark if confirmed by toxicology test” and “alcohol involved?”</P>
                <P>○ Q12 “Diagnosis”: change the question order and move the data field after Q11. Revise prior instruction of “list up to 4 diagnoses” to “list all diagnoses” to enhances new DAWN's ability to identify novel drug, drug trends, and drug outbreaks.</P>
                <P>○ Q13 “Type of Case”: remove instruction language of “using the decision tree.” Revise the existing option of “seeking detox” to “seeking detox and/or substance abuse treatment only” and remove age restriction for “Alcohol only” option to include cases involving alcohol as the only substance of all ages.</P>
                <P>○ Q14, Q15, and Q16 “Was naloxone/buprenorphine/methadone administered to the patient in the ED”: added to capture new data on the implementation of medication-assisted treatment for opioid use disorder in the emergency department setting and understand why buprenorphine and methadone is administered.</P>
                <P>○ Q17 “Disposition”: add new options and re-categorize disposition to improve data accuracy and comprehensiveness and better understand where the patient went after their ED visit.</P>
                <P>• Proposes a new Activity Report From to be submitted by the abstractors to collect information on the date of ED visits the abstractor has reviewed, counts of ED visits for that date, number of records reviewed, and number of left without being seen (LWBS) visits for the ED visit date if participating hospitals choose the direct chart review option.</P>
                <P>The estimated annual burden for the DAWN data collection is as follows:</P>
                <GPOTABLE COLS="8" OPTS="L2,p7,7/8,i1" CDEF="s100,12,12,12,12,12,12,12">
                    <TTITLE> </TTITLE>
                    <BOXHD>
                        <CHED H="1">
                            Information
                            <LI>collection activities</LI>
                        </CHED>
                        <CHED H="1">
                            Number of
                            <LI>respondents</LI>
                        </CHED>
                        <CHED H="1">
                            Responses
                            <LI>per</LI>
                            <LI>respondent</LI>
                        </CHED>
                        <CHED H="1">
                            Total
                            <LI>responses</LI>
                        </CHED>
                        <CHED H="1">
                            Hours per
                            <LI>response</LI>
                            <LI>(in hours)</LI>
                        </CHED>
                        <CHED H="1">
                            Total
                            <LI>burden</LI>
                            <LI>hours</LI>
                        </CHED>
                        <CHED H="1">
                            Average
                            <LI>hourly</LI>
                            <LI>wage</LI>
                        </CHED>
                        <CHED H="1">
                            Total
                            <LI>annual</LI>
                            <LI>cost</LI>
                        </CHED>
                    </BOXHD>
                    <ROW EXPSTB="07" RUL="s">
                        <ENT I="21">
                            <E T="02">Setting Up Activities *</E>
                        </ENT>
                    </ROW>
                    <ROW EXPSTB="00">
                        <ENT I="01">Initial outreach and recruitment (all hospitals)</ENT>
                        <ENT>143</ENT>
                        <ENT>1</ENT>
                        <ENT>143</ENT>
                        <ENT>81.50</ENT>
                        <ENT>11,655</ENT>
                        <ENT>$48.72</ENT>
                        <ENT>$567,807</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">ED record provision setting up (direct chart review)</ENT>
                        <ENT>58</ENT>
                        <ENT>1</ENT>
                        <ENT>58</ENT>
                        <ENT>5.25</ENT>
                        <ENT>305</ENT>
                        <ENT>26.71</ENT>
                        <ENT>8,133</ENT>
                    </ROW>
                    <ROW RUL="s">
                        <ENT I="01">ED record provision setting up (ML with NLP)</ENT>
                        <ENT>85</ENT>
                        <ENT>1</ENT>
                        <ENT>85</ENT>
                        <ENT>36.00</ENT>
                        <ENT>3,060</ENT>
                        <ENT>26.71</ENT>
                        <ENT>81,733</ENT>
                    </ROW>
                    <ROW EXPSTB="07" RUL="s">
                        <ENT I="21">
                            <E T="02">Ongoing Maintenance Activities</E>
                        </ENT>
                    </ROW>
                    <ROW EXPSTB="00">
                        <ENT I="01">Ongoing Maintenance (direct chart review)</ENT>
                        <ENT>58</ENT>
                        <ENT>1</ENT>
                        <ENT>58</ENT>
                        <ENT>1.50</ENT>
                        <ENT>87</ENT>
                        <ENT>26.71</ENT>
                        <ENT>2,324</ENT>
                    </ROW>
                    <ROW RUL="n,s">
                        <ENT I="01">Ongoing Maintenance (ML with NLP)</ENT>
                        <ENT>85</ENT>
                        <ENT>1</ENT>
                        <ENT>85</ENT>
                        <ENT>6.00</ENT>
                        <ENT>510</ENT>
                        <ENT>26.71</ENT>
                        <ENT>13,622</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Totals</ENT>
                        <ENT/>
                        <ENT/>
                        <ENT/>
                        <ENT/>
                        <ENT>15,616</ENT>
                        <ENT/>
                        <ENT>673,619</ENT>
                    </ROW>
                    <TNOTE>* Setting up activities will be conducted once.</TNOTE>
                </GPOTABLE>
                <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>
                <SIG>
                    <NAME>Alicia Broadus,</NAME>
                    <TITLE>Public Health Advisor.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2024-17142 Filed 8-2-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-2024-0284]</DEPDOC>
                <SUBJECT>National Merchant Mariner Medical Advisory Committee; Vacancies</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>U.S. Coast Guard, Department of Homeland Security.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice; request for applications.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The U.S. Coast Guard is accepting applications to fill twelve (12) vacancies on the National Merchant Mariner Medical Advisory Committee (Committee). This Committee advises, consults with, and makes recommendations to the Secretary of the Department of Homeland Security through the Commandant of the United States Coast Guard on matters relating to medical certification determinations for the issuance of licenses, certification of registry, and merchant mariners' documents with respect to merchant mariners; medical standards and guidelines for the physical qualifications of operators of commercial vessels; medical examiner education; and medical research.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Completed applications must reach the U.S. Coast Guard on or before September 4, 2024.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Applications must include (a) a cover letter expressing interest in an appointment to the National Merchant Mariner Medical Advisory Committee, (b) a resume detailing the applicant's relevant experience and qualifications for the position applied for (including the mariner reference number for professional mariners, and licensure, certification, or training information for health-care professionals), and (c) a brief biography. Applications should be submitted via email with subject line “Application for NMEDMAC” to 
                        <E T="03">pamela.j.moore@uscg.mil.</E>
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Ms. Pamela Moore, Alternate Designated Federal Officer of the National Merchant Mariner Medical Advisory Committee; telephone 202-372-1361 or email at 
                        <E T="03">pamela.j.moore@uscg.mil.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    The National Merchant Mariner Medical Advisory Committee is a Federal advisory committee. The Committee was established by section 601 of the 
                    <E T="03">Frank LoBiondo Coast Guard Authorization Act of 2018</E>
                     (Pub. L. 115-282, 132 Stat. 4192), and is codified in 46 U.S.C. 15104. The Committee operates under the provisions of the Federal Advisory Committee Act and 46 U.S.C. 15109.
                </P>
                <P>
                    The Committee is required to meet at least once a year in accordance with 46 U.S.C. 15109(a). We expect the 
                    <PRTPAGE P="63440"/>
                    Committee will hold meetings at least twice a year, at locations across the country selected by the U.S. Coast Guard.
                </P>
                <P>Under provisions in 46 U.S.C. 15109(f)(6), if you are appointed as a member of the Committee, your membership term will expire on December 31st of the third full year after the effective date of your appointment. Under provisions in 46 U.S.C. 15109(f)(4) the Secretary of Homeland Security may require an individual to have passed an appropriate security background examination before appointment to the Committee.</P>
                <P>All members serve at their own expense and receive no salary or other compensation from the Federal Government. The only compensation the members may receive is for travel expenses, including per diem in lieu of subsistence, actual reasonable expenses, or both, incurred in the performance of their direct duties for the Committee in accordance with Federal Travel Regulations. If you are appointed as a member of the Committee, you will be required to sign a Non-Disclosure Agreement and a Gratuitous Service Agreement.</P>
                <P>In this solicitation for Committee members, we will consider applications for twelve (12) positions:</P>
                <P>• Eight positions for health-care professionals with particular expertise, knowledge, and experience regarding the medical examinations of merchant mariners or occupational medicine; and</P>
                <P>• Four positions for professional mariners with particular expertise, knowledge, and experience in occupational requirements for mariners.</P>
                <P>Applicants for the Committee should document their particular expertise, knowledge, and experience on matters relating to (1) medical certification determinations for the issuance of licenses, certification of registry, and merchant mariners' documents with respect to United States merchant mariners; (2) medical standards and guidelines for the physical qualifications of operators of commercial vessels; (3) medical examiner education; and (4) medical research. Professional mariners should include their United States mariner reference number for all credentials currently or previously held. Health-care professionals should include information on relevant licensure, certification, or training.</P>
                <P>
                    <E T="03">Prohibition:</E>
                     Please be aware, that in accordance with 46 U.S.C. 15109 (f)(5)(A), a Federal employee may not be appointed as a member of this Committee.
                </P>
                <P>In order for the Department, to fully leverage broad-ranging experience and education, the National Merchant Mariner Medical Advisory Committee must be diverse with regard to professional and technical expertise. The Department is committed to pursuing opportunities, consistent with applicable law, to compose a committee that reflects the diversity of the Nation's people.</P>
                <P>The U.S. Coast Guard will not consider incomplete or late applications.</P>
                <HD SOURCE="HD1">Privacy Act Statement</HD>
                <P>
                    <E T="03">Purpose:</E>
                     To obtain qualified applicants to fill twelve (12) vacancies on the National Merchant Mariner Medical Advisory Committee. When you apply for appointment to the DHS' National Merchant Mariner Medical Advisory Committee, DHS collects your name, contact information, and any other personal information that you submit in conjunction with your application. DHS will use this information to evaluate your candidacy for Committee membership. If you are chosen to serve as a Committee member, your name will appear in publicly-available Committee documents, membership lists, and Committee reports.
                </P>
                <P>
                    <E T="03">Authorities:</E>
                     14 U.S.C. 504; 46 U.S.C. 15104 and 15109; and 18 U.S.C. 202(a), and Department of Homeland Security Delegation No. 00915.
                </P>
                <P>
                    <E T="03">Routine Uses:</E>
                     Authorized U.S. Coast Guard personnel will use this information to consider and obtain qualified candidates to serve on the Committee. Any external disclosures of information within this record will be made in accordance with DHS/ALL-009, Department of Homeland Security Advisory Committee (73 FR 57639, October 3, 2008).
                </P>
                <P>
                    <E T="03">Consequences of Failure To Provide Information:</E>
                     Furnishing this information is voluntary. However, failure to furnish the requested information may result in your application not being considered for the Committee.
                </P>
                <SIG>
                    <DATED>Dated: July 30, 2024.</DATED>
                    <NAME>Jeffrey G. Lantz,</NAME>
                    <TITLE>Director of Commercial Regulations and Standards.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17159 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 9110-04-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">DEPARTMENT OF HOUSING AND URBAN DEVELOPMENT</AGENCY>
                <DEPDOC>[Docket No. FR-7092-N-35]</DEPDOC>
                <SUBJECT>Privacy Act of 1974; System of Records</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Office of Administration, 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 Administration, Office of the Executive Secretariat (Exec Sec) is issuing a public notice of its intent to modify the Privacy Act system of records titled “Correspondence Tracking System (CTS)”. This system of records is being revised to make clarifying changes within: System Location, System Manager, Record Authority for Maintenance of the System, Purpose of the System, Categories of Individuals Covered by the System, Categories of Records in the System, Records Source Categories, Routine Uses of Records Maintained in the System, Retrieval of Records, and Retention and Disposal of Records, and make general updates to the remaining sections to accurately reflect management of the system of records in accordance with the Office of Management and Budget (OMB) Circular A108, Federal Agency Responsibilities for Review, Reporting, and Publication under the Privacy Act.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Comments will be accepted on or before September 4, 2024. This action shall be effective August 5, 2024. Routine uses 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 the following methods:</P>
                    <P>
                        <E T="03">Federal e-Rulemaking Portal:</E>
                          
                        <E T="03">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.
                    </P>
                    <P>
                        <E T="03">Email:</E>
                          
                        <E T="03">www.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">http://www.regulations.gov.</E>
                         including any personal information provided.
                        <PRTPAGE P="63441"/>
                    </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, the Privacy Office; 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>HUD, the Office of the Executive Secretariat (Exec Sec) maintains the Correspondence Tracking System (CTS) system. HUD is publishing this revised notice to reflect new and modified routine uses, and new source protocols implemented to support HUD's updates. Additionally, administrative updates are being added to the remaining SORN sections to reflect the system in its current state. The change to the system of records will have no undue impact on the privacy of individuals and updates will be consistent with the records collected.</P>
                <P>The following are updates since the previous SORN publication:</P>
                <P>
                    1. 
                    <E T="03">System Number:</E>
                     Updated to classify new system of records number designation to alignment with HUD's system of records inventory.
                </P>
                <P>
                    2. 
                    <E T="03">System Manager:</E>
                     Updated to identify a new system manager.
                </P>
                <P>
                    3. 
                    <E T="03">Purpose of the System:</E>
                     Updated to apply non-substantive changes to identify system functions with clarity and conciseness for public awareness.
                </P>
                <P>
                    4. 
                    <E T="03">Categories of Individuals Covered:</E>
                     Updated to add existing system user groups and purpose the user group serves.
                </P>
                <P>
                    5. 
                    <E T="03">Records Source Categories:</E>
                     Updated, with record sources for internal and external systems, to cover all record sources for system programs.
                </P>
                <P>
                    6. 
                    <E T="03">Records Retention and Disposition:</E>
                     Updated to reflect current retention requirements.
                </P>
                <P>
                    7. 
                    <E T="03">Policy and Practice for Retrieval of Records:</E>
                     Updated to include minor changes and format.
                </P>
                <PRIACT>
                    <HD SOURCE="HD2">SYSTEM NAME AND NUMBER:</HD>
                    <P>Correspondence Tracking System (CTS), HUD/ADM-09.</P>
                    <HD SOURCE="HD2">SECURITY CLASSIFICATION:</HD>
                    <P>Unclassified.</P>
                    <HD SOURCE="HD2">SYSTEM LOCATION:</HD>
                    <P>HUD Headquarters location, 451 7th Street SW, Washington, DC 20410-0001.</P>
                    <HD SOURCE="HD2">SYSTEM MANAGER(S):</HD>
                    <P>Juanita Johnson, System Manager, Office of Systems and Technology, 451 Seventh Street SW, Room 2242, Washington, DC 20410, telephone number (202) 402-5348.</P>
                    <HD SOURCE="HD2">AUTHORITY FOR MAINTENANCE OF THE SYSTEM:</HD>
                    <P>Sections 2 and 7(d) of the Department of Housing and Urban Development Act of 1965, Public Law 89-174.</P>
                    <HD SOURCE="HD2">PURPOSE(S) OF THE SYSTEM:</HD>
                    <P>CTS will allow users and management to track and report on correspondence throughout the workflow process. HUD uses information in CTS to provide appropriate responses to inquiries. CTS will streamline the collection of inquiries from the public regarding their requests for assistance with HUD funded programs.</P>
                    <HD SOURCE="HD2">CATEGORIES OF INDIVIDUALS COVERED BY THE SYSTEM:</HD>
                    <P>Individuals who correspond with HUD's Secretary, Deputy Secretary, or Assistant Secretaries, Individuals whose correspondence has been referred by the White House, other federal agencies, or Members of Congress to the Secretary or Deputy Secretary.</P>
                    <HD SOURCE="HD2">CATEGORIES OF RECORDS IN THE SYSTEM:</HD>
                    <P>Correspondence: name, home address, email address(es), home telephone number(s), work telephone number(s), legal documents and records, requesters, attorneys or representatives' names, fax number, office information, case identifier.</P>
                    <HD SOURCE="HD2">RECORD SOURCE CATEGORIES:</HD>
                    <P>Records are provided by individuals.</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 a congressional office from the record of an individual, in response to an inquiry from the congressional office made at the request of that individual.</P>
                    <P>(2) To contractors, grantees, experts, consultants and their agents, or others performing or working under a contract, service, grant, or cooperative agreement with HUD, when necessary to accomplish an agency function related to a system of records. Disclosure requirements are limited to only those data elements considered relevant to accomplishing an agency function. Contractors provided information under these routine use conditions are subject to Privacy Act requirements and disclosure limitations imposed on the Department.</P>
                    <P>(3) To contractors, experts, and consultants with whom HUD has a contract, service agreement, or other assignment of the Department, when necessary to utilize data to test new technology and systems designed to enhance program operations and performance.</P>
                    <P>(4) To appropriate agencies, entities, and persons when (1) HUD suspects or has confirmed there has breached the system of records; (2) HUD has determined that because of the suspected or confirmed breach there is a risk of harm to individuals, HUD (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 HUD's efforts to respond to the suspected or confirmed breach or to prevent, minimize, or remedy such harm.</P>
                    <P>(5) To another Federal agency or Federal entity, when HUD determines that information from this system of record 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>(6) To appropriate Federal, State, local, tribal, or other governmental agencies or multilateral governmental organizations responsible for investigating or prosecuting the violations of, or for enforcing or implementing, a statute, rule, regulation, order, or license, where HUD determines that the information would assist in the enforcement of civil or criminal laws and when such records, either alone or in conjunction with other information, indicate a violation or potential violation of law.</P>
                    <P>
                        (7) To a court, magistrate, administrative tribunal, or arbitrator in the course of presenting evidence, including disclosures to opposing counsel or witnesses in the course of civil discovery, litigation, mediation, or settlement negotiations, or in connection with criminal law proceedings; when HUD determines that use of such records is relevant and necessary to the litigation and when any of the following is a party to the litigation or have an interest in such litigation: (1) HUD, or any component thereof; or (2) any HUD employee in his or her official capacity; or (3) any HUD 
                        <PRTPAGE P="63442"/>
                        employee in his or her individual capacity where HUD has agreed to represent the employee; or (4) the United States, or any agency thereof, where HUD determines that litigation is likely to affect HUD or any of its components.
                    </P>
                    <P>(8) To any component of the Department of Justice or other Federal agency conducting litigation or in proceedings before any court, adjudicative, or administrative body, when HUD determines that the use of such records is relevant and necessary to the litigation and when any of the following is a party to the litigation or have an interest in such litigation: (1) HUD, or any component thereof; or (2) any HUD employee in his or her official capacity; or (3) any HUD employee in his or her individual capacity where the Department of Justice or agency conducting the litigation has agreed to represent the employee; or (4) the United States, or any agency thereof, where HUD determines that litigation is likely to affect HUD or any of its components.</P>
                    <P>(9) To the National Archives and Records Administration, Office of Government Information Services (OGIS), to the extent necessary to fulfill its responsibilities in 5 U.S.C. 552(h), 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>
                    <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>Name and case number.</P>
                    <HD SOURCE="HD2">POLICIES AND PRACTICES FOR RETENTION AND DISPOSAL OF RECORDS:</HD>
                    <P>Destroyed upon verification of successful creation of the final document or file or when no longer needed for business use, whichever is later.</P>
                    <HD SOURCE="HD2">ADMINISTRATIVE, TECHNICAL, AND PHYSICAL SAFEGUARDS:</HD>
                    <P>
                        <E T="03">For Electronic Records:</E>
                         All personal data will be maintained on a secure workstation or virtual server that is protected by a firewall and complex passwords in a directory that can only be accessed by the system administrators and the analysts actively working on the data; the system used to process or store data have Federal security controls applied to them; the data will be backed up on a regular basis to safeguard against system failures or disasters; and, unencrypted data will not be stored on a laptop or on removable media such as CDs, diskettes, or USB flash drives. Electronic Records are maintained and stored in an electronic encryption database system. These records can only be accessed based on the user's rights and privileges to the system. A multifactor identification method is required which consists of the several layers of security to access the records, such as a valid common access card, access to HUD's network with a valid User ID and password.
                    </P>
                    <P>
                        <E T="03">For Paper Records:</E>
                         The analysts will securely store any hard copy forms with personal identifiers until they are archived; all hard copy forms with personal identifying data will be stored securely in a locked cabinet that can only be accessed by authorized individuals working on the data.
                    </P>
                    <HD SOURCE="HD2">RECORD ACCESS PROCEDURES:</HD>
                    <P>Individuals requesting records of themselves should address written inquiries to the Department of Housing and Urban 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 24 CFR 16.4.</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 24 CFR 16.8 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 24 CFR 16.4.</P>
                    <HD SOURCE="HD2">EXEMPTIONS PROMULGATED FOR THE SYSTEM:</HD>
                    <P>None.</P>
                    <HD SOURCE="HD2">HISTORY:</HD>
                    <P>
                        <E T="03">Docket Citation:</E>
                         72 FR-55801 (October 1, 2007).
                    </P>
                </PRIACT>
                <SIG>
                    <NAME>LaDonne White,</NAME>
                    <TITLE>Chief Privacy Officer, Office of Administration.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17181 Filed 8-2-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-HQ-MB-2024-N039; FXMB1231099BPP0-245-FF09M30000; OMB Control Number 1018-New]</DEPDOC>
                <SUBJECT>Agency Information Collection Activities; Submission to the Office of Management and Budget; National Double-Crested Cormorant Survey</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Fish and Wildlife Service, Interior.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of information collection; request for comment.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>In accordance with the Paperwork Reduction Act of 1995, we, the U.S. Fish and Wildlife Service (Service), are proposing a new information collection in use without approval.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Interested persons are invited to submit comments on or before September 4, 2024.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Written comments and recommendations for the proposed information collection should be submitted within 30 days of publication of this notice at 
                        <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. Please provide a copy of your comments to the Service Information Collection Clearance Officer, U.S. Fish and Wildlife Service, MS: PRB (JAO/3W), 5275 Leesburg Pike, Falls Church, VA 22041-3803 (mail); or by email to 
                        <E T="03">Info_Coll@fws.gov.</E>
                         Please reference “1018-New DCC” in the subject line of your comments.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        To request additional information about this information collection request (ICR), contact Madonna L. Baucum, Service Information Collection Clearance Officer, by email at 
                        <E T="03">Info_Coll@fws.gov,</E>
                         or by telephone at (703) 358-2503. Individuals in the United States who are deaf, deafblind, hard of hearing, or have a speech disability may dial 711 (TTY, TDD, or TeleBraille) to access telecommunications relay 
                        <PRTPAGE P="63443"/>
                        services. Individuals outside the United States should use the relay services offered within their country to make international calls to the point-of-contact in the United States. You may also view the ICR at 
                        <E T="03">https://www.reginfo.gov/public/do/PRAMain.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    In accordance with the Paperwork Reduction Act (PRA, 44 U.S.C. 3501 
                    <E T="03">et seq.</E>
                    ) and its implementing regulations at 5 CFR 1320.8(d)(1), all information collections require approval under the PRA. We may not conduct or sponsor and you are not required to respond to a collection of information unless it displays a currently valid OMB control number.
                </P>
                <P>
                    On April 22, 2024, we published in the 
                    <E T="04">Federal Register</E>
                     (89 FR 29361) a notice of our intent to request that OMB approve this information collection. In that notice, we solicited comments for 60 days, ending on June 21, 2024. In an effort to increase public awareness of, and participation in, our public commenting processes associated with information collection requests, the Service also published the 
                    <E T="04">Federal Register</E>
                     notice on 
                    <E T="03">Regulations.gov</E>
                     (Docket No. FWS-HQ-MB-2024-0044) to provide the public with an additional method to submit comments (in addition to the typical U.S. mail submission method). We received three comments in response to the notice. However, none of the comments addressed the information collection requirements; therefore, no response is required.
                </P>
                <P>As part of our continuing effort to reduce paperwork and respondent burdens, we invite the public and other Federal agencies to comment on new, proposed, revised, and continuing collections of information. This helps us assess the impact of our information collection requirements and minimize the public's reporting burden. It also helps the public understand our information collection requirements and provide the requested data in the desired format.</P>
                <P>We are especially interested in public comment addressing the following:</P>
                <P>(1) Whether or not the collection of information is necessary for the proper performance of the functions of the agency, including whether or not the information will have practical utility;</P>
                <P>(2) The accuracy of our estimate of the burden for this collection of information, including the validity of the methodology and assumptions used;</P>
                <P>(3) Ways to enhance the quality, utility, and clarity of the information to be collected; and</P>
                <P>
                    (4) How might the agency minimize the burden of the collection of information on those who are to respond, including through the use of appropriate automated, electronic, mechanical, or other technological collection techniques or other forms of information technology, 
                    <E T="03">e.g.,</E>
                     permitting electronic submission of response.
                </P>
                <P>Comments that you submit in response to this notice are a matter of public record. We will include or summarize each comment in our request to OMB to approve this ICR. Before including your address, phone number, email address, or other personal identifying information in your comment, you should be aware that your entire comment—including your personal identifying information—may be made publicly available at any time. While you can ask us in your comment to withhold your personal identifying information from public review, we cannot guarantee that we will be able to do so.</P>
                <P>
                    <E T="03">Abstract:</E>
                     The U.S. Fish and Wildlife Service (Service, we) is the Federal agency delegated with the primary responsibility for managing migratory birds. Our authority derives from the Migratory Bird Treaty Act of 1918 (MBTA; 16 U.S.C. 703-712), as amended, which implements conventions with Great Britain (for Canada), Mexico, Japan, and Russia. We implement the provisions of the MBTA through the regulations in parts 10, 13, 20, 21, 22, and 92 of title 50 of the Code of Federal Regulations (CFR). The MBTA protects migratory birds (listed in 50 CFR 10.13) from take directed at birds, except as authorized under the MBTA. Regulations pertaining to specific migratory bird permit types are at 50 CFR parts 21 and 22.
                </P>
                <P>
                    The double-crested cormorant (cormorant; 
                    <E T="03">Phalacrocorax auritus</E>
                    ) is a fish-eating migratory bird that is distributed across a large portion of North America. There are five different breeding populations—the Alaska, Pacific (or Western), Interior, Atlantic, and Southern populations. Although each of these populations is categorized by breeding range, the populations commingle to various extents on their migration and wintering areas, with birds from populations closer to each other overlapping more than those that are more distant.
                </P>
                <P>
                    In response to ongoing damage at aquaculture facilities and other damage and conflicts associated with increasing cormorant populations, the Service administers regulations that authorize the take of cormorants through regular depredation permits (50 CFR 21.100) or the special double-crested cormorant permit available only to State and Tribal fish and wildlife agencies (50 CFR 21.123). Take through these two permit types is supported by assessments that were completed in 2017 and 2020 under the National Environmental Policy Act (NEPA; 42 U.S.C. 4321 
                    <E T="03">et seq.</E>
                    ). The 2017 environmental assessment (EA) supported issuance of depredation permits (82 FR 52936; November 15, 2017), and the 2020 environmental impact statement (EIS) supported creation of the special double-crested cormorant permit (85 FR 85535; December 29, 2020). To determine sustainable take of cormorants, the 2020 EIS contained a potential take limit (PTL) assessment that is used to inform permitting decisions.
                </P>
                <P>Federal, State, Tribal, and many private entities share the Service's goal of maintaining sustainable cormorant populations. Many of these entities conduct cormorant monitoring and contribute to ongoing research and regional or local cormorant management efforts. However, to date, coordinated monitoring across the four North American flyways (Pacific, Central, Mississippi, and Atlantic), with shared objectives and standardized sampling design, does not exist. The desire to enhance existing monitoring efforts was shared in comments by States, Tribes, nongovernment organizations, and members of the public during the 2020 rulemaking process. Therefore, the Service committed to work in partnership with the Flyways to develop a monitoring program for each subpopulation of cormorants. In the 2020 final EIS, the Service made the commitment to monitor cormorant populations and produce a report every 5 years that provides analyses from population monitoring and other status information. The survey, developed in coordination with the four Flyways and conducted initially in 2024, is scheduled to be repeated every 5 years in order to update population estimates and PTL assessments.</P>
                <P>A combination of Federal (Service and U.S. Department of Agriculture Wildlife Services) and State biologists, coordinated through Flyway working groups, conducted the survey during April through June 2024. All surveys will use a standardized data sheet that documents the following:</P>
                <P>1. Completion data:</P>
                <P>a. State, county, names of observers, and agency; and</P>
                <P>b. Date/time, weather conditions (wind, sky, temperature).</P>
                <P>2. Nesting colony information:</P>
                <P>a. Colony name;</P>
                <P>b. Latitude/longitude;</P>
                <P>c. Whether the colony was existing, reestablished, or new;</P>
                <P>
                    d. Nest substrate; and
                    <PRTPAGE P="63444"/>
                </P>
                <P>e. Site habitat condition.</P>
                <P>
                    3. Method used to survey the colony (
                    <E T="03">i.e.,</E>
                     ground count or aerial count).
                </P>
                <P>4. Nest counts:</P>
                <P>a. Number of active or inactive nests (with number of unknown);</P>
                <P>b. Whether the entire colony was surveyed;</P>
                <P>c. Whether co-nesting species were observed; and</P>
                <P>d. Whether photos and/or videos were taken.</P>
                <P>5. General comments from the observer.</P>
                <P>To be flexible, States will have the option to use an electronic version of the datasheet (ArcGIS Survey123 software) or a paper-based survey form. The data the Service collects through the range-wide cormorant monitoring program will be used to update cormorant population estimates and to update PTL assessments with the most up-to-date information as specified in the 2020 EIS. The updated take limits would also inform future Service permit allocation. The Service will share the population estimates and PTL assessments with State and Tribal fish and wildlife agencies to inform their respective management actions, as well as with other Federal agencies, including the U.S. Department of Agriculture Wildlife Services program.</P>
                <P>
                    <E T="03">Title of Collection:</E>
                     National Double-Crested Cormorant Survey.
                </P>
                <P>
                    <E T="03">OMB Control Number:</E>
                     1018-New.
                </P>
                <P>
                    <E T="03">Form Number:</E>
                     None.
                </P>
                <P>
                    <E T="03">Type of Review:</E>
                     New.
                </P>
                <P>
                    <E T="03">Respondents/Affected Public:</E>
                     State/local/Tribal government (State biologists coordinated through the four North American Flyways (Pacific, Central, Mississippi, and Atlantic)).
                </P>
                <P>
                    <E T="03">Total Estimated Number of Annual Respondents:</E>
                     40.
                </P>
                <P>
                    <E T="03">Total Estimated Number of Annual Responses:</E>
                     1,016.
                </P>
                <P>
                    <E T="03">Estimated Completion Time per Response:</E>
                     4 hours (30 minutes reporting and 3.5 hours recordkeeping).
                </P>
                <P>
                    <E T="03">Total Estimated Number of Annual Burden Hours:</E>
                     4,064.
                </P>
                <P>
                    <E T="03">Respondent's Obligation:</E>
                     Voluntary.
                </P>
                <P>
                    <E T="03">Frequency of Collection:</E>
                     One time.
                </P>
                <P>
                    <E T="03">Total Estimated Annual Nonhour Burden Cost:</E>
                     None.
                </P>
                <P>An agency may not conduct or sponsor and a person is not required to respond to a collection of information unless it displays a currently valid OMB control number.</P>
                <P>
                    The authority for this action is the Paperwork Reduction Act of 1995 (44 U.S.C. 3501 
                    <E T="03">et seq.</E>
                    ).
                </P>
                <SIG>
                    <NAME>Madonna Baucum,</NAME>
                    <TITLE>Information Collection Clearance Officer, U.S. Fish and Wildlife Service.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17234 Filed 8-2-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>[MTM-56312-01]</DEPDOC>
                <SUBJECT>Public Land Order No. 7945; Extension of Public Land Order No. 6560, as Extended by Public Land Order No. 7610; Withdrawal of Wisdom Administrative Site; Montana</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 Public Land Order (PLO) extends the duration of the withdrawal created by PLO No. 6560, as extended by PLO No. 7610, which would otherwise expire August 5, 2024, for an additional 20-year period. PLO No. 6560 withdrew 59.99 acres of public domain land outside the exterior boundary of the Beaverhead-Deerlodge National Forest from settlement, sale, location, or entry, under the general land laws, including the mining laws, subject to valid existing rights, and transferred administrative jurisdiction to the United States Forest Service (USFS) for use as the Wisdom Administrative Site.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>This PLO takes effect on August 6, 2024.</P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Adam Carr, Branch Chief, Realty Lands and Renewable Energy, BLM Montana/Dakotas, 5001 South Gate Drive, Billings, Montana 59101, telephone: (406) 538-1957; email: 
                        <E T="03">acarr@blm.gov;</E>
                         or Nathan Teats, Land Status Program Manager, U.S. Forest Service Region One, Office of the Regional Forester, 26 Fort Missoula Road, Missoula Montana 59804, telephone: (406) 329-3193 or email: 
                        <E T="03">nathan.e.teats@usda.gov.</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>The purpose for which the withdrawal was first made requires the withdrawal extension in order to continue to protect and preserve the USFS managed Wisdom Administrative Site, facilities, and capital improvements.</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. Subject to valid existing rights, PLO No. 6560 (49 FR 32068, (1984)), as extended</P>
                <P>by PLO No. 7610 (69 FR 50213, (2004)), which withdrew 59.99 acres of public domain land outside the exterior boundary of the Beaverhead-Deerlodge National Forest from settlement, sale, location, or entry under the general land laws, including the mining laws, and transferred administrative jurisdiction to the USFS to protect and preserve the Wisdom Administrative Site, is hereby extended for an additional 20-year period. The lands being withdrawn in this order are described as follows:</P>
                <EXTRACT>
                    <HD SOURCE="HD1">Principal Meridian, Montana</HD>
                    <FP SOURCE="FP-2">T. 2 S., R. 15 W.,</FP>
                    <FP SOURCE="FP1-2">Sec. 34, Tract A of Certificate of Survey 369, document number 171983 recorded June 25, 1982, filed in Beaverhead County, Montana.</FP>
                    <FP SOURCE="FP-2">T. 3 S., R. 15 W.,</FP>
                    <FP SOURCE="FP1-2">Sec. 3, Tract B of Certificate of Survey 369, document number 171983 recorded June 25, 1982, filed in Beaverhead County, Montana.</FP>
                    <P>The area described contains 59.99 acres.</P>
                </EXTRACT>
                <P>2. The withdrawal made by this order does not alter the applicability of those public land laws governing the use of land other than under the United States mining laws.</P>
                <P>3. The withdrawal extended by this Order will expire 20 years from the effective date of this order, unless, as a result of review conducted prior to the expiration date pursuant to section 204(f) of the Federal Land Policy and Management Act of 1976, 43 U.S.C. 1714(f), the Secretary determines the withdrawal shall be further extended.</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-17357 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 3411-15-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <PRTPAGE P="63445"/>
                <AGENCY TYPE="N">INTERNATIONAL TRADE COMMISSION</AGENCY>
                <DEPDOC>[Investigation Nos. 701-TA-703 and 731-TA-1661-1663 (Final)]</DEPDOC>
                <SUBJECT>Glass Wine Bottles From Chile, China, and Mexico; Revised Schedule for the Subject Investigations</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>United States International Trade Commission.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>July 30, 2024.</P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Charles Cummings (202-708-1666), Office of Investigations, U.S. International Trade Commission, 500 E Street SW, Washington, DC 20436. Hearing-impaired persons can obtain information on this matter by contacting the Commission's TDD terminal on 202-205-1810. Persons with mobility impairments who will need special assistance in gaining access to the Commission should contact the Office of the Secretary at 202-205-2000. General information concerning the Commission may also be obtained by accessing its internet server (
                        <E T="03">https://www.usitc.gov</E>
                        ). The public record for this investigation may be viewed on the Commission's electronic docket (EDIS) at 
                        <E T="03">https://edis.usitc.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>On June 3, 2024, the Commission established a schedule for the conduct of the final phase of the subject investigations (89 FR 49901, June 12, 2024) following the preliminary determination from the U.S. Department of Commerce (“Commerce”) that countervailable subsidies are being provided to producers and exporters of certain glass wine bottles from China (89 FR 47533, June 3, 2024). Subsequently, Commerce placed on the record of this investigation a memorandum extending the date for its final determination in the countervailing duty investigation with respect to China from August 12, 2024 to August 19, 2024. The Commission, therefore, is revising its schedule to conform with Commerce's new schedule.</P>
                <P>The Commission's revised dates in the schedule are as follows: the deadline for filing posthearing briefs is 5:15 p.m. on August 23, 2024; the Commission will make its final release of information on September 13, 2024; and final party comments are due on 5:15 p.m. on September 17, 2024.</P>
                <P>For further information concerning this proceeding, see the Commission's notice cited above and the Commission's Rules of Practice and Procedure, part 201, subparts A through E (19 CFR part 201), and part 207, subparts A and C (19 CFR part 207).</P>
                <P>
                    <E T="03">Authority:</E>
                     These investigations are being conducted under authority of title VII of the Tariff Act of 1930; this notice is published pursuant to § 207.21 of the Commission's rules.
                </P>
                <SIG>
                    <P>By order of the Commission.</P>
                    <DATED>Issued: July 30, 2024.</DATED>
                    <NAME>Lisa Barton,</NAME>
                    <TITLE>Secretary to the Commission.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17200 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 7020-02-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">DEPARTMENT OF LABOR</AGENCY>
                <SUBAGY>Veterans' Employment and Training Service</SUBAGY>
                <SUBJECT>Solicitation of Nominations for Appointment to the Advisory Committee on Veterans' Employment, Training, and Employer Outreach (ACVETEO)</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Veterans' Employment and Training Service (VETS), Department of Labor (DOL).</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Solicitation of nominations.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>Veterans' Employment and Training Service is seeking nominations of qualified candidates to be considered for appointment as members of the Advisory Committee on Veterans' Employment, Training, and Employer Outreach (ACVETEO, or the Committee). The Secretary of Labor will appoint at least 12, but no more than 16, members who serve as Special Government Employees.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Nominations for membership on the Committee must be received no later than 11:59 p.m. EST on September 30, 2024. Packages received after this time will not be considered for the current membership cycle.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        All nomination packages must be sent by email to the Designated Federal Official to 
                        <E T="03">ACVETEO@dol.gov</E>
                         subject line “2025 ACVETEO Nomination”.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Mr. Gregory Green, Designated Federal Official for the ACVETEO, 
                        <E T="03">ACVETEO@dol.gov,</E>
                         (202) 693-4734. Additional information regarding the Committee, including its charter, current membership list, annual reports and meeting minutes, may be found at 
                        <E T="03">https://www.dol.gov/agencies/vets/about/advisorycommittee.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>The ACVETEO is a Congressionally mandated advisory committee authorized under title 38, U.S. Code, section 4110 and subject to the Federal Advisory Committee Act, 5 U.S.C. 10. The ACVETEO is responsible for: assessing employment and training needs of veterans; determining the extent to which the programs and activities of the U.S. Department of Labor meet these needs; assisting to conduct outreach to employers seeking to hire veterans; making recommendations to the Secretary, through the Assistant Secretary for Veterans' Employment and Training Service, with respect to outreach activities and employment and training needs of veterans; and carrying out such other activities necessary to make required reports and recommendations. DOL is soliciting nominations for members to serve on the Committee. As required by statute, the members of the Committee are appointed by the Secretary from the general public.</P>
                <P>Members will consist of: (1) seven individuals, one each from among the representatives nominated by (a) the Society for Human Resource Management, (b) the Business Roundtable, (c) National Association of State Workforce Agencies, (d) the United States Chamber of Commerce, (e) the National Federation of Independent Business, (f) a nationally recognized labor union or organization and (g) the National Governors Association; (2) no more than five representatives nominated by Veterans Service Organizations that have a national employment program; and (3) no more than five individuals who are recognized authorities in the fields of business, employment, training, rehabilitation, or labor and who are not employees of DOL.</P>
                <P>DOL seeks nominees with the following experience:</P>
                <P>(1) Diversity in professional and personal qualifications;</P>
                <P>(2) Experience in military service;</P>
                <P>(3) Current work with veterans;</P>
                <P>(4) Veterans disability subject matter expertise;</P>
                <P>(5) Experience working in large and complex organizations;</P>
                <P>(6) Experience in transition assistance;</P>
                <P>(7) Experience in the protection of employment and reemployment rights;</P>
                <P>(8) Experience in education, skills training, integration into the workforce and outreach;</P>
                <P>(9) Understanding of licensing and credentialing issues; and/or</P>
                <P>(10) Experience in military/veteran apprenticeship programs.</P>
                <P>
                    <E T="03">Requirements for Nomination Submission:</E>
                     Combine all application materials into one PDF (one nomination per nominator). Failure to follow guidance may result in your nomination 
                    <PRTPAGE P="63446"/>
                    package being rejected. The nomination package must be submitted in the following order and include:
                </P>
                <P>
                    (1) Letter of nomination that clearly states the name and affiliation of the nominee, the basis for the nomination (
                    <E T="03">i.e.,</E>
                     specific attributes, including military service, if applicable, that qualifies the nominee for service in this capacity)
                </P>
                <P>(2) Statement from the nominee indicating willingness to regularly attend and participate in Committee meetings;</P>
                <P>(3) Nominee's contact information, including name, mailing address, telephone number(s), and email address;</P>
                <P>(4) Nominee's curriculum vitae or resume;</P>
                <P>(5) Summary of the nominee's experience and qualifications relative to the experience listed above;</P>
                <P>(6) Nominee biography;</P>
                <P>(7) Provide a summary of the Veterans Service Organization's (VSO) national employment program: To be considered a national employment program, the VSO must offer nationwide access to employment resources for veterans seeking employment.</P>
                <P>
                    (8) Recognition as a VSO accredited by the Department of Veterans Affairs through the Office of the General Counsel, listed on this site: 
                    <E T="03">https://www.va.gov/ogc/apps/accreditation/index.asp.</E>
                </P>
                <P>(9) Statement that the nominee has no apparent conflicts of interest that would preclude membership.</P>
                <P>(10) 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 an Advisory Committee member if the nominee becomes a federally registered lobbyist.</P>
                <P>Individuals selected for appointment to the Committee will be reimbursed for per diem and travel for attending in-person Committee meetings. The Department makes every effort to ensure that the membership of its Federal advisory committees is fairly balanced in terms of points of view represented. Every effort is made to ensure that a broad representation of geographic areas, gender, racial and ethnic minority groups, and the disabled are given consideration for membership. Appointment to this Committee shall be made without discrimination because of a person's race, color, religion, sex (including gender identity, transgender status, sexual orientation, and pregnancy), national origin, age, disability, or genetic information. An ethics review is conducted for each selected nominee.</P>
                <SIG>
                    <DATED>Signed at Washington, DC, on July 29th, 2024.</DATED>
                    <NAME>James D. Rodriquez,</NAME>
                    <TITLE>Assistant Secretary, Veterans' Employment and Training Service.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17221 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4510-79-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">NATIONAL SCIENCE FOUNDATION</AGENCY>
                <SUBJECT>Notice of Permit Applications Received Under the Antarctic Conservation Act of 1978</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>National Science Foundation.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of permit applications received.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The National Science Foundation (NSF) is required to publish a notice of permit applications received to conduct activities regulated under the Antarctic Conservation Act of 1978. NSF has published regulations under the Antarctic Conservation Act in the Code of Federal Regulations. This is the required notice of permit applications received.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Interested parties are invited to submit written data, comments, or views with respect to this permit application by September 4, 2024. This application may be inspected by interested parties at the Permit Office, address below.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Comments should be addressed to Permit Office, Office of Polar Programs, National Science Foundation, 2415 Eisenhower Avenue, Alexandria, Virginia 22314 or 
                        <E T="03">ACApermits@nsf.gov.</E>
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Andrew Titmus, ACA Permit Officer, at the above address, 703-292-4479.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>The National Science Foundation, as directed by the Antarctic Conservation Act of 1978 (Pub. L. 95-541, 45 CFR 670), as amended by the Antarctic Science, Tourism and Conservation Act of 1996, has developed regulations for the establishment of a permit system for various activities in Antarctica and designation of certain animals and certain geographic areas as requiring special protection. The regulations establish such a permit system to designate Antarctic Specially Protected Areas.</P>
                <HD SOURCE="HD1">Application Details</HD>
                <HD SOURCE="HD2">Permit Application: 2025-010</HD>
                <FP SOURCE="FP-1">
                    1. 
                    <E T="03">Applicant:</E>
                     Daniel Costa, 130 MacAlister Way, University of California, Santa Cruz, CA 95060
                </FP>
                <P>
                    <E T="03">Activity for Which Permit is Requested:</E>
                     Take, Harmful Interference, Enter Antarctic Specially Protected Area, Import into USA, Export from USA. The applicant seeks an ACA permit in association with research on the foraging ecology of Weddell seals. The applicant would capture, weigh, measure, sample, and tag up to 25 adult Weddell seals. Additionally, up to 10 Crabeater seal adults, up to 5 Ross seal adults, up to 5 Leopard seal adults, and up to 5 Elephant seal adults would be captured, weighed, measured, sampled, and tagged. Seals would be chemically immobilized using sedatives including telazol, ketamine-diazepam, ketamine-midazolam, and butorphanol-midazolam during handling. This approach has been used during previous work in the Ross Sea, and is currently permitted under a NMFS Marine Mammal permit valid until November 30, 2026. Samples taken would include whiskers, blood, muscle and blubber biopsies. Seals would be flipper tagged and instrumented with a satellite data logger, total handling time would be under 1 hour per animal. Work would be conducted in ASPA 124—Cape Crozier, as well as ASPA 105—Beaufort Island, ASPA 116—New College Valley, ASPA 121—Cape Royds, ASPA 155—Cape Evans, and ASPA 157—Backdoor Bay.
                </P>
                <P>
                    <E T="03">Location:</E>
                     ASPA 105—Beaufort Island, McMurdo Sound, Ross Sea; ASPA 116—New College Valley, Caughley Beach, Cape Bird, Ross Island; ASPA 121—Cape Royds, Ross Island; ASPA 124—Cape Crozier, Ross Island; ASPA 155—Cape Evans, Ross Island; ASPA 157—Backdoor Bay, Cape Royds, Ross Island.
                </P>
                <P>
                    <E T="03">Dates of Permitted Activities:</E>
                     October 1, 2024-September 30, 2024.
                </P>
                <SIG>
                    <NAME>Kimiko S. Bowens-Knox,</NAME>
                    <TITLE>Program Analyst, Office of Polar Programs.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17206 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 7555-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">NATIONAL SCIENCE FOUNDATION</AGENCY>
                <SUBJECT>Notice of Permit Applications Received Under the Antarctic Conservation Act of 1978</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>National Science Foundation.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of permit applications received.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The National Science Foundation (NSF) is required to publish a notice of permit applications received to conduct activities regulated under the Antarctic Conservation Act of 1978. NSF has published regulations under the Antarctic Conservation Act in the Code of Federal Regulations. This is the required notice of permit applications received.</P>
                </SUM>
                <DATES>
                    <PRTPAGE P="63447"/>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Interested parties are invited to submit written data, comments, or views with respect to this permit application by September 4, 2024. This application may be inspected by interested parties at the Permit Office, address below.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Comments should be addressed to Permit Office, Office of Polar Programs, National Science Foundation, 2415 Eisenhower Avenue, Alexandria, Virginia 22314 or 
                        <E T="03">ACApermits@nsf.gov.</E>
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Andrew Titmus, ACA Permit Officer, at the above address, 703-292-4479.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>The National Science Foundation, as directed by the Antarctic Conservation Act of 1978 (Pub. L. 95-541, 45 CFR part 671), as amended by the Antarctic Science, Tourism and Conservation Act of 1996, has developed regulations for the establishment of a permit system for various activities in Antarctica and designation of certain animals and certain geographic areas as requiring special protection. The regulations establish such a permit system to designate Antarctic Specially Protected Areas.</P>
                <HD SOURCE="HD1">Application Details</HD>
                <HD SOURCE="HD2">Permit Application: 2025-009</HD>
                <FP SOURCE="FP-1">
                    1. 
                    <E T="03">Applicant:</E>
                     Chris Linder, Potomac MD, 20854
                </FP>
                <P>
                    <E T="03">Activity for Which Permit is Requested:</E>
                     Waste Management. The applicant seeks and Antarctic Conservation Act permit to fly a small battery-operated remotely piloted aircrafts (RPAS) to take scenic photos and film of the Antarctic. The RPAS would not be flown over concentrations of birds or mammals or over Antarctic Specially Protected Areas. The RPAS would only be flown by the applicant who has extensive piloting experience in fair weather conditions. Several measures would be taken to prevent against loss of the RPAS. The applicant is seeking a Waste Permit to cover any accidental releases that may result from flying a UAV.
                </P>
                <P>
                    <E T="03">Location:</E>
                     Antarctic Peninsula Region.
                </P>
                <P>
                    <E T="03">Dates of Permitted Activities:</E>
                     January 14, 2025-January 30, 2025.
                </P>
                <SIG>
                    <NAME>Kimiko S. Bowens-Knox,</NAME>
                    <TITLE>Program Analyst, Office of Polar Programs.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17212 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 7555-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">NUCLEAR REGULATORY COMMISSION</AGENCY>
                <DEPDOC>[NRC-2023-0111]</DEPDOC>
                <SUBJECT>Interim Staff Guidance: Use of the Decommissioning Trust Fund During Operations for Major Radioactive Component Disposal</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Nuclear Regulatory Commission.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Final guidance; issuance.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The U.S. Nuclear Regulatory Commission (NRC) is issuing Interim Staff Guidance (ISG) REFS-ISG-2024-01, “Use of the Decommissioning Trust Fund During Operations for Major Radioactive Component Disposal.” The purpose of this ISG is to provide the NRC staff's regulatory position to licensees of nuclear power reactors regarding the use of funds from the decommissioning trust fund (DTF) dedicated to the radiological decommissioning of a reactor facility for the disposal of major radioactive components (MRCs) while the facility is in an operational status. This final ISG may be used in connection with requests for exemption from NRC regulations related to the withdrawal of funds from reactor DTFs.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>This guidance is effective on September 4, 2024.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>Please refer to Docket ID NRC-2023-0111 when contacting the NRC about the availability of information regarding this document. You may obtain publicly available information related to this document using any of the following methods:</P>
                    <P>
                        • 
                        <E T="03">Federal Rulemaking Website:</E>
                         Go to 
                        <E T="03">https://www.regulations.gov</E>
                         and search for Docket ID NRC-2023-0111. Address questions about Docket IDs in 
                        <E T="03">Regulations.gov</E>
                         to Stacy Schumann; telephone: 301-415-0624; email: 
                        <E T="03">Stacy.Schumann@nrc.gov.</E>
                         For technical questions, contact the individual listed in the 
                        <E T="02">For Further Information Contact</E>
                         section of this document.
                    </P>
                    <P>
                        • 
                        <E T="03">NRC's Agencywide Documents Access and Management System (ADAMS):</E>
                         You may obtain publicly available documents online in the ADAMS Public Documents collection at 
                        <E T="03">https://www.nrc.gov/reading-rm/adams.html.</E>
                         To begin the search, select “Begin Web-based ADAMS Search.” For problems with ADAMS, please contact the NRC's Public Document Room (PDR) reference staff at 1-800-397-4209, at 301-415-4737, or by email to 
                        <E T="03">PDR.Resource@nrc.gov.</E>
                         The ISG, REFS-ISG-2024-01 on the “Use of the Decommissioning Trust Fund During Operations for Major Radioactive Component Disposal” is available in ADAMS under Accession No. ML24114A263.
                    </P>
                    <P>
                        • 
                        <E T="03">NRC's PDR:</E>
                         The PDR, where you may examine and order copies of publicly available documents, is open by appointment. To make an appointment to visit the PDR, please send an email to 
                        <E T="03">PDR.Resource@nrc.gov</E>
                         or call 1-800-397-4209 or 301-415-4737, between 8 a.m. and 4 p.m. eastern time (ET), Monday through Friday, except Federal holidays.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Shawn Harwell, Office of Nuclear Material Safety and Safeguards, U.S. Nuclear Regulatory Commission, Washington, DC 20555-0001; telephone: 301-415-1309; email: 
                        <E T="03">Shawn.Harwell@nrc.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">I. Background</HD>
                <P>
                    On June 21, 2023, the NRC issued a 
                    <E T="04">Federal Register</E>
                     notice (88 FR 40337) soliciting public comment on its draft ISG, “Use of the Decommissioning Trust Fund During Operations for Major Radioactive Component Disposal.” The NRC received comments from Lili Lamar Shari Laskowitz, by letter dated August 20, 2023 (ADAMS Accession No. ML23236A525), Paul Saunders, by letter dated June 29, 2023 (ADAMS Accession No. ML23181A049), Lili Lamar Zucker Ashley Humphries, by letter dated August 20, 2023 (ADAMS Accession No. ML23236A527), John J. Sipos, by letter dated September 13, 2023 (ADAMS Accession No. ML23262B451), the Appalachian Compact Commission, by letter dated July 28, 2023 (ADAMS Accession No. ML23236A522), the Nuclear Energy Institute, by letter dated August 21, 2023 (ADAMS Accession No. ML23236A529), EnergySolutions, by letter dated August 21, 2023 (ADAMS Accession No. ML23236A528) and from Constellation Energy Generation, LLC, by letter dated August 21, 2023 (ADAMS Accession No. ML23236A531). No other comments were submitted. The NRC staff considered those comments in developing the final version of the ISG. The staff's responses to the comments are provided in Appendix A, “Disposition of Public Comments,” of the final ISG.
                </P>
                <P>
                    This ISG is intended to provide clarifying guidance to facilitate stakeholder understanding of the NRC's position on the use of the DTF during operations for MRC disposal. The NRC's reactor licensing regulations in part 50 of title 10 of the 
                    <E T="03">Code of Federal Regulations</E>
                     (10 CFR), “Domestic Licensing of Production and Utilization 
                    <PRTPAGE P="63448"/>
                    Facilities,” establish requirements for providing assurance that funding will be available to radiologically decommission a reactor facility and terminate the part 50 license. Specifically, these requirements address, among other things, the amount of decommissioning funding to be provided, the methods to be used for assuring sufficient funding, and provisions restricting the use of the DTF during operations.
                </P>
                <P>Two separate petitions for rulemaking (PRM) were submitted to the NRC for consideration in 2008 and 2019 requesting that the NRC revise the definition of Decommissioning in 10 CFR 50.2 and amend 10 CFR 50.82 to allow access to the DTF to pay for the cost of the disposal of MRCs prior to permanent cessation of operations at nuclear power plants. The Commission denied both petitions, noting the subject is adequately covered by existing regulations, including the exemption process in 10 CFR 50.12, “Specific exemptions.” In the analyses recommending denial of the PRMs, the NRC staff noted that any withdrawal of funds from the DTF during operations, other than those allowed by NRC regulations, could undermine the intent of the decommissioning funding regulations. Therefore, only under extraordinary circumstances would a withdrawal from the DTF prior to permanent cessation of operations be permissible.</P>
                <P>The NRC staff evaluates each exemption request for a DTF withdrawal to ensure it meets the criteria for special exemptions in 10 CFR 50.12 and considers the totality of facts in determining whether to grant or deny a request. This ISG discusses the mechanisms which allow the use of a DTF to cover the cost of MRC disposal during operations. Information a licensee may provide that assists the NRC staff in assessing a licensee's exemption request from the regulations related to the use of a DFT is also presented.</P>
                <HD SOURCE="HD1">II. Backfitting, Forward Fitting, and Issue Finality</HD>
                <P>
                    Issuance of this ISG will not (i) constitute backfitting as defined in section 50.109 of title 10 of the 
                    <E T="03">Code of Federal Regulations</E>
                     (10 CFR), “Backfitting,” and as described in Management Directive (MD) 8.4, “Management of Backfitting, Forward Fitting, Issue Finality, and Information Requests”; (ii) affect issue finality of any approval issued under 10 CFR part 52, “Licenses, Certifications, and Approvals for Nuclear Power Plants”; or (iii) constitute forward fitting as that term is defined and described in MD 8.4. This ISG states the NRC staff's position on the use of decommissioning trust funds during operations for disposal and lists examples of factors that the NRC staff would consider when evaluating exemption requests under 10 CFR 50.12. Applicants and licensees will not be required to comply with the positions set forth in this ISG.
                </P>
                <HD SOURCE="HD1">III. Congressional Review Act</HD>
                <P>This ISG is not a rule as defined in the Congressional Review Act (5 U.S.C. 801-808).</P>
                <SIG>
                    <P>Dated: July 30, 2024.</P>
                    <P>For the Nuclear Regulatory Commission.</P>
                    <NAME>John Moses,</NAME>
                    <TITLE>Deputy Director, Division of Rulemaking, Environmental, and Financial Support, Office of Nuclear Material Safety and Safeguards.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17236 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 7590-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">NUCLEAR REGULATORY COMMISSION</AGENCY>
                <DEPDOC>[NRC-2024-0026]</DEPDOC>
                <SUBJECT>Information Collection: Planned Power Uprate-Related Licensing Submittals for All Power Reactor Licensees</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Nuclear Regulatory Commission.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of submission to the Office of Management and Budget; request for comment.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The U.S. Nuclear Regulatory Commission (NRC) has recently submitted a proposed collection of information to the Office of Management and Budget (OMB) for review. The information collection is entitled, “Planned Power Uprate-Related Licensing Submittals for All Power Reactor Licensees.”</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Submit comments by September 4, 2024. Comments received after this date will be considered if it is practical to do so, but the Commission is able to ensure consideration only for comments received on or before this date.</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">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.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        David Cullison, NRC Clearance Officer, U.S. Nuclear Regulatory Commission, Washington, DC 20555-0001; telephone: 301-415-2084; email: 
                        <E T="03">Infocollects.Resource@nrc.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">I. Obtaining Information and Submitting Comments</HD>
                <HD SOURCE="HD2">A. Obtaining Information</HD>
                <P>Please refer to Docket ID NRC-2024-0026 when contacting the NRC about the availability of information for this action. You may obtain publicly available information related to this action by any of the following methods:</P>
                <P>
                    • 
                    <E T="03">Federal Rulemaking Website:</E>
                     Go to 
                    <E T="03">https://www.regulations.gov</E>
                     and search for Docket ID NRC-2024-0026.
                </P>
                <P>
                    • 
                    <E T="03">NRC's Agencywide Documents Access and Management System (ADAMS):</E>
                     You may obtain publicly available documents online in the ADAMS Public Documents collection at 
                    <E T="03">https://www.nrc.gov/reading-rm/adams.html.</E>
                     To begin the search, select “Begin Web-based ADAMS Search.” For problems with ADAMS, please contact the NRC's Public Document Room (PDR) reference staff at 1-800-397-4209, at 301-415-4737, or by email to 
                    <E T="03">PDR.Resource@nrc.gov.</E>
                     The supporting statement, Regulatory Issue Summary, and burden table are available in ADAMS under Accession Nos. ML24183A233, ML23353A201, and ML24018A171.
                </P>
                <P>
                    • 
                    <E T="03">NRC's PDR:</E>
                     The PDR, where you may examine and order copies of publicly available documents, is open by appointment. To make an appointment to visit the PDR, please send an email to 
                    <E T="03">PDR.Resource@nrc.gov</E>
                     or call 1-800-397-4209 or 301-415-4737, between 8 a.m. and 4 p.m. eastern time (ET), Monday through Friday, except Federal holidays.
                </P>
                <P>
                    • 
                    <E T="03">NRC's Clearance Officer:</E>
                     A copy of the collection of information and related instructions may be obtained without charge by contacting the NRC's Clearance Officer, David Cullison, Office of the Chief Information Officer, U.S. Nuclear Regulatory Commission, Washington, DC 20555-0001; telephone: 301-415-2084; email: 
                    <E T="03">Infocollects.Resource@nrc.gov.</E>
                </P>
                <HD SOURCE="HD2">B. Submitting Comments</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">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.
                </P>
                <P>
                    The NRC cautions you not to include identifying or contact information in 
                    <PRTPAGE P="63449"/>
                    comment submissions that you do not want to be publicly disclosed in your comment submission. All comment submissions are posted at 
                    <E T="03">https://www.regulations.gov</E>
                     and entered into ADAMS. Comment submissions are not routinely edited to remove identifying or contact information.
                </P>
                <P>If you are requesting or aggregating comments from other persons for submission to the OMB, then you should inform those persons not to include identifying or contact information that they do not want to be publicly disclosed in their comment submission. Your request should state that comment submissions are not routinely edited to remove such information before making the comment submissions available to the public or entering the comment into ADAMS.</P>
                <HD SOURCE="HD1">II. Background</HD>
                <P>Under the provisions of the Paperwork Reduction Act of 1995 (44 U.S.C. Chapter 35), the NRC recently submitted a proposed collection of information to OMB for review entitled “Planned Power Uprate-Related Licensing Submittals for All Power Reactor Licensees.” The NRC hereby informs potential respondents that an agency may not conduct or sponsor, and that a person is not required to respond to, a collection of information unless it displays a currently valid OMB control number.</P>
                <P>
                    The NRC published a 
                    <E T="04">Federal Register</E>
                     notice with a 60-day comment period on this information collection on April 29, 2024, 89 FR 33402.
                </P>
                <P>
                    1. 
                    <E T="03">The title of the information collection:</E>
                     Planned Power Uprate-Related Licensing Submittals for All Power Reactor Licensees.
                </P>
                <P>
                    2. 
                    <E T="03">OMB approval number:</E>
                     An OMB control number has not yet been assigned to this proposed information collection.
                </P>
                <P>
                    3. 
                    <E T="03">Type of submission:</E>
                     New.
                </P>
                <P>
                    4. 
                    <E T="03">The form number, if applicable:</E>
                     Not applicable.
                </P>
                <P>
                    5. 
                    <E T="03">How often the collection is required or requested:</E>
                     Annually, with the addition of voluntary updates as available.
                </P>
                <P>
                    6. 
                    <E T="03">Who will be required or asked to respond:</E>
                     All holders of operating licenses or combined licenses for nuclear power reactors, except those that have permanently ceased operations and have certified that fuel has been permanently removed from the reactor vessel or combined license holders that have not received authorization to load nuclear fuel and begin operation.
                </P>
                <P>
                    7. 
                    <E T="03">The estimated number of annual responses:</E>
                     5.33.
                </P>
                <P>
                    8. 
                    <E T="03">The estimated number of annual respondents:</E>
                     5.33.
                </P>
                <P>
                    9. 
                    <E T="03">The estimated number of hours needed annually to comply with the information collection requirement or request:</E>
                     107.
                </P>
                <P>
                    10. 
                    <E T="03">Abstract:</E>
                     This voluntary information collection assists the NRC in determining resource and budget needs as well as aligning the proper allocation and utilization of resources to support power uprate related licensing activities. In addition, information provided to the NRC staff is intended to promote early communications between the NRC and the respective addressees about potential power uprate licensing actions, submission dates, and related activities to support power uprates, such as alternate source term amendments or accident tolerant fuels amendment activities. The overarching goal of this information collection is to assist the NRC staff more effectively and efficiently plan, schedule, and implement activities and reviews in a timely manner.
                </P>
                <SIG>
                    <DATED>Dated: July 30, 2024.</DATED>
                    <P>For the Nuclear Regulatory Commission.</P>
                    <NAME>David Cullison,</NAME>
                    <TITLE>NRC Clearance Officer, Office of the Chief Information Officer.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17149 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 7590-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">NUCLEAR REGULATORY COMMISSION</AGENCY>
                <DEPDOC>[NRC-2023-0150]</DEPDOC>
                <SUBJECT>Information Collection: Licensing Requirements for the Independent Storage of Spent Nuclear Fuel and High-Level Radioactive Waste and Reactor-Related Greater than Class C Waste</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Nuclear Regulatory Commission.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of submission to the Office of Management and Budget; request for comment.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The U.S. Nuclear Regulatory Commission (NRC) has recently submitted a request for renewal of an existing collection of information to the Office of Management and Budget (OMB) for review. The information collection is entitled, “Licensing Requirements for the Independent Storage of Spent Nuclear Fuel and High-Level Radioactive Waste and Reactor-Related Greater than Class C Waste.”</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Submit comments by September 4, 2024. Comments received after this date will be considered if it is practical to do so, but the Commission is able to ensure consideration only for comments received on or before this date.</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">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.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        David Cullison, NRC Clearance Officer, U.S. Nuclear Regulatory Commission, Washington, DC 20555-0001; telephone: 301-415-2084; email: 
                        <E T="03">Infocollects.Resource@nrc.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">I. Obtaining Information and Submitting Comments</HD>
                <HD SOURCE="HD2">A. Obtaining Information</HD>
                <P>Please refer to Docket ID NRC-2023-0150 when contacting the NRC about the availability of information for this action. You may obtain publicly available information related to this action by any of the following methods:</P>
                <P>
                    • 
                    <E T="03">Federal Rulemaking Website:</E>
                     Go to 
                    <E T="03">https://www.regulations.gov</E>
                     and search for Docket ID NRC-2023-0150.
                </P>
                <P>
                    • 
                    <E T="03">NRC's Agencywide Documents Access and Management System (ADAMS):</E>
                     You may obtain publicly available documents online in the ADAMS Public Documents collection at 
                    <E T="03">https://www.nrc.gov/reading-rm/adams.html.</E>
                     To begin the search, select “Begin Web-based ADAMS Search.” For problems with ADAMS, please contact the NRC's Public Document Room (PDR) reference staff at 1-800-397-4209, at 301-415-4737, or by email to 
                    <E T="03">PDR.Resource@nrc.gov.</E>
                     The supporting statement and information collection burden tables are available in ADAMS under Accession Nos. ML24151A353 and ML24151A355, respectively.
                </P>
                <P>
                    • 
                    <E T="03">NRC's PDR:</E>
                     The PDR, where you may examine and order copies of publicly available documents, is open by appointment. To make an appointment to visit the PDR, please send an email to 
                    <E T="03">PDR.Resource@nrc.gov</E>
                     or call 1-800-397-4209 or 301-415-4737, between 8 a.m. and 4 p.m. eastern time (ET), Monday through Friday, except Federal holidays.
                </P>
                <P>
                    • 
                    <E T="03">NRC's Clearance Officer:</E>
                     A copy of the collection of information and related instructions may be obtained without charge by contacting the NRC's Clearance Officer, David Cullison, Office of the Chief Information Officer, U.S. Nuclear Regulatory Commission, Washington, DC 20555-0001; telephone: 
                    <PRTPAGE P="63450"/>
                    301-415-2084; email: 
                    <E T="03">Infocollects.Resource@nrc.gov.</E>
                </P>
                <HD SOURCE="HD2">B. Submitting Comments</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">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.
                </P>
                <P>
                    The NRC cautions you not to include identifying or contact information in comment submissions that you do not want to be publicly disclosed in your comment submission. All comment submissions are posted at 
                    <E T="03">https://www.regulations.gov</E>
                     and entered into ADAMS. Comment submissions are not routinely edited to remove identifying or contact information.
                </P>
                <P>If you are requesting or aggregating comments from other persons for submission to the OMB, then you should inform those persons not to include identifying or contact information that they do not want to be publicly disclosed in their comment submission. Your request should state that comment submissions are not routinely edited to remove such information before making the comment submissions available to the public or entering the comment into ADAMS.</P>
                <HD SOURCE="HD1">II. Background</HD>
                <P>Under the provisions of the Paperwork Reduction Act of 1995 (44 U.S.C. chapter 35), the NRC recently submitted a request for renewal of an existing collection of information to OMB for review entitled, “Licensing Requirements for the Independent Storage of Spent Nuclear Fuel and High-Level Radioactive Waste and Reactor-Related Greater than Class C Waste.” The NRC hereby informs potential respondents that an agency may not conduct or sponsor, and that a person is not required to respond to, a collection of information unless it displays a currently valid OMB control number.</P>
                <P>
                    The NRC published a 
                    <E T="04">Federal Register</E>
                     notice with a 60-day comment period on this information collection on April 5, 2024, 89 FR 24043.
                </P>
                <P>
                    1. 
                    <E T="03">The title of the information collection:</E>
                     Licensing Requirements for the Independent Storage of Spent Nuclear Fuel and High-Level Radioactive Waste and Reactor-Related Greater than Class C Waste.
                </P>
                <P>
                    2. 
                    <E T="03">OMB approval number:</E>
                     3150-0132.
                </P>
                <P>
                    3. 
                    <E T="03">Type of submission:</E>
                     Extension.
                </P>
                <P>
                    4. 
                    <E T="03">The form number, if applicable:</E>
                     Not applicable.
                </P>
                <P>
                    5. 
                    <E T="03">How often the collection is required or requested:</E>
                     Required reports are collected and evaluated on a continuing basis as events occur; submittal of reports varies from less than one per year under some rule sections to up to an average of about 80 per year under other rule sections. Applications for new licenses, certificates of compliance (CoCs), and amendments may be submitted at any time; applications for renewal of licenses are required every 40 years for an independent spent fuel storage installation (ISFSI) or CoC effective May 21, 2011, and every 40 years for a monitored retrievable storage (MRS) facility.
                </P>
                <P>
                    6. 
                    <E T="03">Who will be required or asked to respond:</E>
                     Certificate holders and applicants for a CoC for spent fuel storage casks; licensees and applicants for a license to possess power reactor spent fuel and other radioactive materials associated with spent fuel storage in an ISFSI; and the Department of Energy for licenses to receive, transfer, package and possess power reactor spent fuel, high-level waste, and other radioactive materials associated with spent fuel and high-level waste storage in an MRS.
                </P>
                <P>
                    7. 
                    <E T="03">The estimated number of annual responses:</E>
                     858.
                </P>
                <P>
                    8. 
                    <E T="03">The estimated number of annual respondents:</E>
                     89.
                </P>
                <P>
                    9. 
                    <E T="03">The estimated number of hours needed annually to comply with the information collection requirement or request:</E>
                     78,466.
                </P>
                <P>
                    10. 
                    <E T="03">Abstract:</E>
                     10 CFR part 72, establishes mandatory requirements, procedures, and criteria for the issuance of licenses to receive, transfer, and possess power reactor spent fuel and other radioactive materials associated with spent fuel storage in an ISFSI, as well as requirements for the issuance of licenses to the Department of Energy to receive, transfer, package, and possess power reactor spent fuel and high-level radioactive waste, and other associated radioactive materials in an MRS. The information in the applications, reports, and records is used by NRC to make licensing and other regulatory determinations.
                </P>
                <SIG>
                    <DATED>Dated: July 31, 2024.</DATED>
                    <P>For the Nuclear Regulatory Commission.</P>
                    <NAME>David Cullison,</NAME>
                    <TITLE>NRC Clearance Officer, Office of the Chief Information Officer. </TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17190 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 7590-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">NUCLEAR REGULATORY COMMISSION</AGENCY>
                <DEPDOC>[Docket Nos. 50-237 and 50-249; NRC-2024-0080]</DEPDOC>
                <SUBJECT>Constellation Energy Generation, LLC; Dresden Nuclear Power Station, Units 2 and 3; Notice of Intent To Conduct Scoping Process and Prepare Environmental Impact Statement</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Nuclear Regulatory Commission.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice; public scoping meeting and request for comment.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The U.S. Nuclear Regulatory Commission (NRC) will conduct a scoping process to gather information necessary to prepare an environmental impact statement (EIS) to evaluate the environmental impacts for the subsequent license renewal (SLR) of Renewed Facility Operating License Nos. DPR-19 and DPR-25, which authorize Constellation Energy Generation, LLC (CEG, the applicant) to operate Dresden Nuclear Power Station (Dresden), Units 2 and 3. The NRC staff is seeking public comment on this action and has scheduled two public scoping meetings that will take place as online webinars.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>
                        The NRC will hold two public scoping meetings as online webinars on August 20, 2024, from 12 p.m. to 2 p.m. central time (CT) and from 5 p.m. to 7 p.m. CT. Details on both meetings can be found on the NRC's Public Meeting Schedule at 
                        <E T="03">https://www.nrc.gov/pmns/mtg.</E>
                         Submit comments on the scope of the EIS by September 4, 2024. Comments received after this date will be considered if it is practical to do so, but the NRC is able to ensure consideration only for comments received on or before this date.
                    </P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>You may submit comments by any of the following methods; however, the NRC encourages electronic comment submission through the Federal rulemaking website.</P>
                    <P>
                        • 
                        <E T="03">Federal rulemaking website:</E>
                         Go to 
                        <E T="03">https://www.regulations.gov</E>
                         and search for Docket ID NRC-2024-0080. Address questions about Docket IDs in 
                        <E T="03">Regulations.gov</E>
                         to Stacy Schumann; telephone: 301-415-0624; email: 
                        <E T="03">Stacy.Schumann@nrc.gov.</E>
                         For technical questions, contact the individual listed in the 
                        <E T="02">For Further Information Contact</E>
                         section of this document.
                    </P>
                    <P>
                        • 
                        <E T="03">Email comments to: DresdenEnvironmental@nrc.gov.</E>
                    </P>
                    <P>
                        • 
                        <E T="03">Mail comments to:</E>
                         Office of Administration, Mail Stop: TWFN-7-A60M, U.S. Nuclear Regulatory Commission, Washington, DC 20555-
                        <PRTPAGE P="63451"/>
                        0001, ATTN: Program Management, Announcements and Editing Staff.
                    </P>
                    <P>
                        For additional directions on obtaining information and submitting comments, see “Obtaining Information and Submitting Comments” in the 
                        <E T="02">SUPPLEMENTARY INFORMATION</E>
                         section of this document.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Tam Tran, Office of Nuclear Material Safety and Safeguards, U.S. Nuclear Regulatory Commission, Washington, DC 20555-0001; telephone: 301-415-3617; email: 
                        <E T="03">Tam.Tran@nrc.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">I. Obtaining Information and Submitting Comments</HD>
                <HD SOURCE="HD2">A. Obtaining Information</HD>
                <P>Please refer to Docket ID NRC-2024-0080 when contacting the NRC about the availability of information for this action. You may obtain publicly available information related to this action by any of the following methods:</P>
                <P>
                    • 
                    <E T="03">Federal Rulemaking Website:</E>
                     Go to 
                    <E T="03">https://www.regulations.gov</E>
                     and search for Docket ID NRC-2024-0080.
                </P>
                <P>
                    • 
                    <E T="03">NRC's Agencywide Documents Access and Management System (ADAMS):</E>
                     You may obtain publicly available documents online in the ADAMS Public Documents collection at 
                    <E T="03">https://www.nrc.gov/reading-rm/adams.html.</E>
                     To begin the search, select “Begin Web-based ADAMS Search.” For problems with ADAMS, please contact the NRC's Public Document Room (PDR) reference staff at 1-800-397-4209, at 301-415-4737, or by email to 
                    <E T="03">PDR.Resource@nrc.gov.</E>
                     The ADAMS accession number for each document referenced in this document (if it is available in ADAMS) is provided the first time that it is referenced.
                </P>
                <P>
                    • 
                    <E T="03">NRC's PDR:</E>
                     The PDR, where you may examine and order copies of publicly available documents, is open by appointment. To make an appointment to visit the PDR, please send an email to 
                    <E T="03">PDR.Resource@nrc.gov</E>
                     or call 1-800-397-4209 or 301-415-4737, between 8 a.m. and 4 p.m. ET, Monday through Friday, except Federal holidays.
                </P>
                <P>
                    • 
                    <E T="03">Public Library:</E>
                     A copy of the SLR application for Dresden, including the applicant's environmental report, will be available for public review at the following public library locations: Morris Area Public Library, 604 Liberty St., Morris, IL 60450, and Coal City Library, 85 N Garfield Street, Coal City, IL 60416.
                </P>
                <HD SOURCE="HD2">B. Submitting Comments</HD>
                <P>
                    The NRC encourages electronic comment submission through the Federal rulemaking website (
                    <E T="03">https://www.regulations.gov</E>
                    ). Please include Docket ID NRC-2024-0080 in your comment submission.
                </P>
                <P>
                    The NRC cautions you not to include identifying or contact information that you do not want to be publicly disclosed in your comment submission. The NRC will post all comment submissions at 
                    <E T="03">https://www.regulations.gov</E>
                     as well as enter the comment submissions into ADAMS. The NRC does not routinely edit comment submissions to remove identifying or contact information.
                </P>
                <P>If you are requesting or aggregating comments from other persons for submission to the NRC, then you should inform those persons not to include identifying or contact information that they do not want to be publicly disclosed in their comment submission. Your request should state that the NRC does not routinely edit comment submissions to remove such information before making the comment submissions available to the public or entering the comment into ADAMS.</P>
                <HD SOURCE="HD1">II. Discussion</HD>
                <P>
                    By letter dated April 17, 2024 (ADAMS Package Accession No. ML24108A007), CEG submitted to the NRC an application for SLR of Renewed Facility Operating License Nos. DPR-19 and DPR-25 for Dresden, Units 2 and 3, for an additional 20 years of operation. This submission initiated the NRC's proposed action of determining whether to grant the SLR application. Dresden is located in Morris IL, approximately 23 miles southwest of Joliet, IL. The current facility operating license for Dresden, Unit 2, expires at midnight on December 22, 2029, and the current facility operating license for Dresden, Unit 3 expires at midnight on January 12, 2031. The SLR application was submitted pursuant to part 54 of title 10 of the 
                    <E T="03">Code of Federal Regulations</E>
                     (10 CFR), “Requirements for Renewal of Operating Licenses for Nuclear Power Plants,” and seeks to extend the facility operating license for Unit 2 to midnight on December 22, 2049, and Unit 3 to midnight January 12, 2051. A notice of receipt and availability of the application was published in the 
                    <E T="04">Federal Register</E>
                     on May 7, 2024 (89 FR 38197). A notice of acceptance for docketing of the application and of opportunity to request a hearing was published in the 
                    <E T="04">Federal Register</E>
                     on June 24, 2024 (89 FR 52514) and is available on the Federal rulemaking website (
                    <E T="03">https://www.regulations.gov</E>
                    ) by searching for Docket ID NRC-2024-0080.
                </P>
                <HD SOURCE="HD1">III. Request for Comment</HD>
                <P>This notice informs the public of the NRC staff's intent to conduct environmental scoping and prepare an EIS related to the SLR application for Dresden, and to provide the public an opportunity to participate in the environmental scoping process, as defined in 10 CFR 51.29 “Scoping-environmental impact statement and supplement to environmental impact statement,” and 10 CFR 51.116, “Notice of intent.”</P>
                <P>
                    The regulations in 36 CFR 800.8, “Coordination with the National Environmental Policy Act,” allow agencies to use their National Environmental Policy Act of 1969, as amended (42 U.S.C. 4321, 
                    <E T="03">et seq.</E>
                    ) (NEPA), process to fulfill the requirements of Section 106 of the National Historic Preservation Act of 1966 (54 U.S.C. 300101, 
                    <E T="03">et seq.</E>
                    ) (NHPA).
                </P>
                <P>Therefore, pursuant to 36 CFR 800.8(c), the NRC staff intends to use its process and documentation required for the preparation of the EIS on the proposed action to comply with Section 106 of the NHPA in lieu of the procedures set forth at 36 CFR 800.3 through 800.6.</P>
                <P>
                    In accordance with the regulations in 10 CFR part 51 and the Commission's decision in CLI-22-2 (ADAMS Accession No. ML22055A496), Dresden submitted an environmental report (ER) as part of the SLR application. The ER is available in ADAMS under Accession No. ML24108A011. The ER is also available for viewing at: 
                    <E T="03">https://www.nrc.gov/reactors/operating/licensing/renewal/applications/Dresden-subsequent.html.</E>
                </P>
                <P>As part of its environmental review, the NRC staff will first conduct a scoping process for the EIS and, as soon as practicable thereafter, will prepare a draft EIS for public comment. Participation in this scoping process by members of the public and local, State, Tribal, and Federal government agencies is encouraged. The scoping process for the EIS will be used to accomplish the following:</P>
                <P>a. Define the proposed action that is to be the subject of the EIS;</P>
                <P>b. Determine the scope of the EIS and identify the significant issues to be analyzed in depth;</P>
                <P>c. Identify and eliminate from detailed study those issues that are peripheral or are not significant or that have been covered by prior environmental review;</P>
                <P>
                    d. Identify any environmental assessments and other ElSs that are being or will be prepared that are related to, but are not part of, the scope of the EIS under consideration;
                    <PRTPAGE P="63452"/>
                </P>
                <P>e. Identify other environmental review and consultation requirements related to the proposed action;</P>
                <P>f. Indicate the relationship between the timing of the preparation of the environmental analyses and the NRC's tentative planning and decision-making schedule;</P>
                <P>g. Identify any cooperating agencies and, as appropriate, allocate assignments for preparation and schedules for completing the EIS to the NRC and any cooperating agencies; and</P>
                <P>h. Describe how the EIS will be prepared, including any contractor assistance to be used.</P>
                <P>The NRC staff invites the following entities to participate in scoping:</P>
                <P>a. The applicant, CEG, LLC;</P>
                <P>b. Any Federal agency that has jurisdiction by law or special expertise with respect to any environmental impact involved or that is authorized to develop and enforce relevant environmental standards;</P>
                <P>c. Affected State and local government agencies, including those authorized to develop and enforce relevant environmental standards;</P>
                <P>d. Any affected Native American Tribe;</P>
                <P>e. Any person who requests or has requested an opportunity to participate in the scoping process; and</P>
                <P>f. Any person who has petitioned or who intends to petition, for leave to intervene in the proceeding under 10 CFR 2.309.</P>
                <HD SOURCE="HD1">IV. Public Scoping Meeting</HD>
                <P>In accordance with 10 CFR 51.26(b), the scoping process for an EIS may include a public scoping meeting to help identify significant issues related to the proposed action and to determine the scope of issues to be addressed in the EIS.</P>
                <P>
                    The NRC is announcing that it will hold two public scoping meetings as online webinars for the Dresden SLR application. Both webinars will include telephone lines for members of the public to provide comments. A court reporter will transcribe all comments received during the webinars. To be considered, comments must be provided either at the transcribed public meeting or in writing, as discussed in the 
                    <E T="02">ADDRESSES</E>
                     section of this document. The public scoping meetings will be held as online webinars on August 20, 2024, from 12 p.m. to 2 p.m. CT and from 5 p.m. to 7 p.m. CT. Persons interested in attending these online webinars should monitor the NRC's Public Meeting Schedule website at 
                    <E T="03">https://www.nrc.gov/pmns/mtg</E>
                     for additional information, agendas for the meeting, and access information for the webinar. Please contact Tam Tran no later than August 9, 2024, if accommodations or special equipment is needed to attend or to provide comments, so that the NRC staff can determine whether the request can be accommodated.
                </P>
                <P>Both public scoping meetings will include: (1) an overview by the NRC staff of the environmental and safety review processes, the proposed scope of the EIS, and the proposed review schedule; and (2) the opportunity for interested government agencies, organizations, and individuals to submit comments or suggestions on environmental issues or the proposed scope of the Dresden SLR EIS.</P>
                <P>Participation in the scoping process for the Dresden SLR EIS does not entitle participants to become parties to the proceeding to which the EIS relates. Matters related to participation in any hearing are outside the scope of matters to be discussed at this public meeting.</P>
                <SIG>
                    <DATED>Dated: July 31, 2024.</DATED>
                    <P>For the Nuclear Regulatory Commission.</P>
                    <NAME>Stephen Koenick,</NAME>
                    <TITLE>Chief, Environmental Project Management Branch 1, Division of Rulemaking, Environment, and Financial Support, Office of Nuclear Material Safety, and Safeguards.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17246 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 7590-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">NUCLEAR REGULATORY COMMISSION</AGENCY>
                <DEPDOC>[NRC-2024-0001]</DEPDOC>
                <SUBJECT>Sunshine Act Meetings</SUBJECT>
                <PREAMHD>
                    <HD SOURCE="HED">TIME AND DATE: </HD>
                    <P>
                        Weeks of August 5, 12, 19, 26, and September 2, 9, 2024. The schedule for Commission meetings is subject to change on short notice. The NRC Commission Meeting Schedule can be found on the internet at: 
                        <E T="03">https://www.nrc.gov/public-involve/public-meetings/schedule.html.</E>
                    </P>
                </PREAMHD>
                <PREAMHD>
                    <HD SOURCE="HED">PLACE: </HD>
                    <P>
                        The NRC provides reasonable accommodation to individuals with disabilities where appropriate. If you need a reasonable accommodation to participate in these public meetings or need this meeting notice or the transcript or other information from the public meetings in another format (
                        <E T="03">e.g.,</E>
                         braille, large print), please notify Anne Silk, NRC Disability Program Specialist, at 301-287-0745, by videophone at 240-428-3217, or by email at 
                        <E T="03">Anne.Silk@nrc.gov.</E>
                         Determinations on requests for reasonable accommodation will be made on a case-by-case basis.
                    </P>
                </PREAMHD>
                <PREAMHD>
                    <HD SOURCE="HED">STATUS: </HD>
                    <P>Public.</P>
                    <P>
                        Members of the public may request to receive the information in these notices electronically. If you would like to be added to the distribution, please contact the Nuclear Regulatory Commission, Office of the Secretary, Washington, DC 20555, at 301-415-1969, or by email at 
                        <E T="03">Betty.Thweatt@nrc.gov</E>
                         or 
                        <E T="03">Samantha.Miklaszewski@nrc.gov.</E>
                    </P>
                </PREAMHD>
                <PREAMHD>
                    <HD SOURCE="HED">MATTERS TO BE CONSIDERED:</HD>
                    <P/>
                </PREAMHD>
                <HD SOURCE="HD1">Week of August 5, 2024</HD>
                <P>There are no meetings scheduled for the week of August 5, 2024.</P>
                <HD SOURCE="HD1">Week of August 12, 2024—Tentative</HD>
                <P>There are no meetings scheduled for the week of August 12, 2024.</P>
                <HD SOURCE="HD1">Week of August 19, 2024—Tentative</HD>
                <P>There are no meetings scheduled for the week of August 19, 2024.</P>
                <HD SOURCE="HD1">Week of August 26, 2024—Tentative</HD>
                <P>There are no meetings scheduled for the week of August 26, 2024.</P>
                <HD SOURCE="HD1">Week of September 2, 2024—Tentative</HD>
                <HD SOURCE="HD2">Thursday, September 5, 2024</HD>
                <FP SOURCE="FP-2">10:00 a.m. All Employees Meeting (Public Meeting) (Contact: Sarah Turner 301-287-9058)</FP>
                <P>
                    <E T="03">Additional Information:</E>
                     The meeting will be held in the Two White Flint North auditorium, 11555 Rockville Pike, Rockville, Maryland. The public is invited to attend the Commission's meeting live by webcast at the Web address—
                    <E T="03">https://video.nrc.gov/.</E>
                </P>
                <HD SOURCE="HD1">Week of September 9, 2024—Tentative</HD>
                <P>There are no meetings scheduled for the week of September 9, 2024.</P>
                <PREAMHD>
                    <HD SOURCE="HED">CONTACT PERSON FOR MORE INFORMATION: </HD>
                    <P>
                        For more information or to verify the status of meetings, contact Sarah Turner at 301-287-9058 or via email at 
                        <E T="03">Sarah.Turner@nrc.gov.</E>
                    </P>
                    <P>The NRC is holding the meetings under the authority of the Government in the Sunshine Act, 5 U.S.C. 552b.</P>
                </PREAMHD>
                <SIG>
                    <DATED>Dated: July 31, 2024.</DATED>
                    <P>For the Nuclear Regulatory Commission.</P>
                    <NAME>Sarah A. Turner,</NAME>
                    <TITLE>Information Management Specialist, Office of the Secretary.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2024-17274 Filed 8-1-24; 11:15 am]</FRDOC>
            <BILCOD>BILLING CODE 7590-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <PRTPAGE P="63453"/>
                <AGENCY TYPE="N">OFFICE OF PERSONNEL MANAGEMENT</AGENCY>
                <DEPDOC>[Docket ID: OPM-2023-0034]</DEPDOC>
                <SUBJECT>Submission for Review: OPM Form 1655, Application for Senior Administrative Law Judge, and OPM Form 1655-A, Geographic Preference Statement for Senior Administrative Law Judge Applicant, OMB Control Number 3206-0248</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Office of Personnel Management.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>30-Day notice and request for comments.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>In accordance with the Paperwork Reduction Act of 1995, the Office of Personnel Management (OPM) is proposing revisions to a currently approved information collection, OMB Control Number, 3206-0248: OPM Form 1655, Application for Senior Administrative Law Judge, and OPM Form 1655-A, Geographic Preference Statement for Senior Administrative Law Judge Applicant.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Comments are encouraged and will be accepted until September 4, 2024.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Written comments and recommendations for proposed information collection requests should be sent within 30 days of publication of this notice to 
                        <E T="03">www.reginfo.gov/public/do/PRAMain.</E>
                         Find this particular information collection request by selecting “Office of Personnel Management” under “Currently Under Review,” then check “Only Show ICR for Public Comment” checkbox.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        For specific questions related to this information collection activities, please contact, Ms. Diane Hobbs, Administrative Law Judge Program Manager at 
                        <E T="03">Diane.Hobbs@opm.gov</E>
                         or (202) 606-3822.
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>OPM, in accordance with the Paperwork Reduction Act of 1995 (PRA) (44 U.S.C. 3506(c)(2)(A)), provides the public with an opportunity to comment on proposed, revised, and continuing collections of information. This helps the Agency assess the impact of its information collection requirements and minimize the public's reporting burden. It also helps the public understand the Agency's information collection requirements and provide the requested data in the desired format.</P>
                <P>OPM is soliciting comments on the proposed information collection request (ICR) that is described below. The Agency is especially interested in public comment addressing the following issues: (1) whether this collection is necessary to the proper functions of the Agency; (2) whether this information will be processed and used in a timely manner; (3) the accuracy of the burden estimate; (4) ways in which the Agency may enhance the quality, utility, and clarity of the information to be collected; and (5) ways in which the Agency may minimize the burden of this collection on the respondents, including through the use of information technology. Written comments received in response to this notice will be considered public records.</P>
                <HD SOURCE="HD1">Analysis</HD>
                <P>
                    <E T="03">Agency:</E>
                     Administrative Law Judge Program Office, Office of Personnel Management.
                </P>
                <P>
                    <E T="03">Title:</E>
                     OPM 1655, Application for Senior Administrative Law Judge, and OPM 1655-A, Geographic Preference Statement for Senior Administrative Law Judge Applicant.
                </P>
                <P>
                    <E T="03">OMB Number:</E>
                     3206-0248.
                </P>
                <P>
                    <E T="03">Affected Public:</E>
                     Federal Administrative Law Judge Retirees.
                </P>
                <P>
                    <E T="03">Number of Respondents:</E>
                     Approximately 150—OPM 1655/Approximately 200—OPM 1655-A.
                </P>
                <P>
                    <E T="03">Estimated Time per Respondent:</E>
                     Approximately 45 Minutes—OPM 1655/Approximately 25 Minutes—OPM 1655-A.
                </P>
                <P>
                    <E T="03">Total Burden Hours:</E>
                     Estimated 113 hours—OPM 1655/Estimated 84 hours—OPM 1655-A.
                </P>
                <SIG>
                    <FP>Office of Personnel Management.</FP>
                    <NAME>Kayyonne Marston,</NAME>
                    <TITLE>Federal Register Liaison.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17238 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6325-43-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">POSTAL REGULATORY COMMISSION</AGENCY>
                <DEPDOC>[Docket Nos. MC2024-458 and CP2024-465; MC2024-460 and CP2024-467; MC2024-461 and CP2024-468; MC2024-462 and CP2024-469; MC2024-463 and CP2024-470]</DEPDOC>
                <SUBJECT>New Postal Products</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Postal Regulatory Commission.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Commission is noticing a recent Postal Service filing for the Commission's consideration concerning a negotiated service agreement. This notice informs the public of the filing, invites public comment, and takes other administrative steps.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>
                        <E T="03">Comments are due:</E>
                         August 7, 2024.
                    </P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Submit comments electronically via the Commission's Filing Online system at 
                        <E T="03">http://www.prc.gov.</E>
                         Those who cannot submit comments electronically should contact the person identified in the 
                        <E T="02">FOR FURTHER INFORMATION CONTACT</E>
                         section by telephone for advice on filing alternatives.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>David A. Trissell, General Counsel, at 202-789-6820.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">Table of Contents</HD>
                <EXTRACT>
                    <FP SOURCE="FP-2">I. Introduction</FP>
                    <FP SOURCE="FP-2">II. Docketed Proceeding(s)</FP>
                </EXTRACT>
                <HD SOURCE="HD1">I. Introduction</HD>
                <P>The Commission gives notice that the Postal Service filed request(s) for the Commission to consider matters related to negotiated service agreement(s). The request(s) may propose the addition or removal of a negotiated service agreement from the Market Dominant or the Competitive product list, or the modification of an existing product currently appearing on the Market Dominant or the Competitive product list.</P>
                <P>Section II identifies the docket number(s) associated with each Postal Service request, the title of each Postal Service request, the request's acceptance date, and the authority cited by the Postal Service for each request. For each request, the Commission appoints an officer of the Commission to represent the interests of the general public in the proceeding, pursuant to 39 U.S.C. 505 (Public Representative). Section II also establishes comment deadline(s) pertaining to each request.</P>
                <P>
                    The public portions of the Postal Service's request(s) can be accessed via the Commission's website (
                    <E T="03">http://www.prc.gov</E>
                    ). Non-public portions of the Postal Service's request(s), if any, can be accessed through compliance with the requirements of 39 CFR 3011.301.
                    <SU>1</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         
                        <E T="03">See</E>
                         Docket No. RM2018-3, Order Adopting Final Rules Relating to Non-Public Information, June 27, 2018, Attachment A at 19-22 (Order No. 4679).
                    </P>
                </FTNT>
                <P>
                    The Commission invites comments on whether the Postal Service's request(s) in the captioned docket(s) are consistent with the policies of title 39. For request(s) that the Postal Service states concern Market Dominant product(s), applicable statutory and regulatory requirements include 39 U.S.C. 3622, 39 U.S.C. 3642, 39 CFR part 3030, and 39 CFR part 3040, subpart B. For request(s) that the Postal Service states concern Competitive product(s), applicable statutory and regulatory requirements include 39 U.S.C. 3632, 39 U.S.C. 3633, 
                    <PRTPAGE P="63454"/>
                    39 U.S.C. 3642, 39 CFR part 3035, and 39 CFR part 3040, subpart B. Comment deadline(s) for each request appear in section II.
                </P>
                <HD SOURCE="HD1">II. Docketed Proceeding(s)</HD>
                <P>
                    1. 
                    <E T="03">Docket No(s).:</E>
                     MC2024-458 and CP2024-465; 
                    <E T="03">Filing Title:</E>
                     USPS Request to Add Priority Mail Express, Priority Mail &amp; USPS Ground Advantage Contract 184 to Competitive Product List and Notice of Filing Materials Under Seal; 
                    <E T="03">Filing Acceptance Date:</E>
                     July 30, 2024; 
                    <E T="03">Filing Authority:</E>
                     39 U.S.C. 3642, 39 CFR 3040.130 through 3040.135, and 39 CFR 3035.105; 
                    <E T="03">Public Representative:</E>
                     Kenneth R. Moeller; 
                    <E T="03">Comments Due:</E>
                     August 7, 2024.
                </P>
                <P>
                    2. 
                    <E T="03">Docket No(s).:</E>
                     MC2024-460 and CP2024-467; 
                    <E T="03">Filing Title:</E>
                     USPS Request to Add Priority Mail Express, Priority Mail &amp; USPS Ground Advantage Contract 185 to Competitive Product List and Notice of Filing Materials Under Seal; 
                    <E T="03">Filing Acceptance Date:</E>
                     July 30, 2024; 
                    <E T="03">Filing Authority:</E>
                     39 U.S.C. 3642, 39 CFR 3040.130 through 3040.135, and 39 CFR 3035.105; 
                    <E T="03">Public Representative:</E>
                     Arif Hafiz; 
                    <E T="03">Comments Due:</E>
                     August 7, 2024.
                </P>
                <P>
                    3. 
                    <E T="03">Docket No(s).:</E>
                     MC2024-461 and CP2024-468; 
                    <E T="03">Filing Title:</E>
                     USPS Request to Add Priority Mail Express, Priority Mail &amp; USPS Ground Advantage Contract 186 to Competitive Product List and Notice of Filing Materials Under Seal; 
                    <E T="03">Filing Acceptance Date:</E>
                     July 30, 2024; 
                    <E T="03">Filing Authority:</E>
                     39 U.S.C. 3642, 39 CFR 3040.130 through 3040.135, and 39 CFR 3035.105; 
                    <E T="03">Public Representative:</E>
                     Arif Hafiz; 
                    <E T="03">Comments Due:</E>
                     August 7, 2024.
                </P>
                <P>
                    4. 
                    <E T="03">Docket No(s).:</E>
                     MC2024-462 and CP2024-469; 
                    <E T="03">Filing Title:</E>
                     USPS Request to Add Priority Mail Express, Priority Mail &amp; USPS Ground Advantage Contract 187 to Competitive Product List and Notice of Filing Materials Under Seal; 
                    <E T="03">Filing Acceptance Date:</E>
                     July 30, 2024; 
                    <E T="03">Filing Authority:</E>
                     39 U.S.C. 3642, 39 CFR 3040.130 through 3040.135, and 39 CFR 3035.105; 
                    <E T="03">Public Representative:</E>
                     Alireza Motameni; 
                    <E T="03">Comments Due:</E>
                     August 7, 2024.
                </P>
                <P>
                    5. 
                    <E T="03">Docket No(s).:</E>
                     MC2024-463 and CP2024-470; 
                    <E T="03">Filing Title:</E>
                     USPS Request to Add Priority Mail Express, Priority Mail &amp; USPS Ground Advantage Contract 188 to Competitive Product List and Notice of Filing Materials Under Seal; 
                    <E T="03">Filing Acceptance Date:</E>
                     July 30, 2024; 
                    <E T="03">Filing Authority:</E>
                     39 U.S.C. 3642, 39 CFR 3040.130 through 3040.135, and 39 CFR 3035.105; 
                    <E T="03">Public Representative:</E>
                     Alireza Motameni; 
                    <E T="03">Comments Due:</E>
                     August 7, 2024.
                </P>
                <P>
                    This Notice will be published in the 
                    <E T="04">Federal Register</E>
                    .
                </P>
                <SIG>
                    <NAME>Jennie L. Jbara,</NAME>
                    <TITLE>Primary Certifying Official.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17208 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 7710-FW-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">SECURITIES AND EXCHANGE COMMISSION</AGENCY>
                <DEPDOC>[Release No. 34-100617; File No. SR-ICC-2024-006]</DEPDOC>
                <SUBJECT>Self-Regulatory Organizations; ICE Clear Credit LLC; Notice of Filing and Immediate Effectiveness of Proposed Rule Change Relating to the Stress Testing Framework</SUBJECT>
                <DATE>July 30, 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 July 16, 2024, ICE Clear Credit LLC (“ICC”) 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 primarily by ICC. ICC filed the proposed rule change pursuant to Section 19(b)(3)(A) 
                    <SU>3</SU>
                    <FTREF/>
                     of the Act and Rule 19b-4(f)(1) 
                    <SU>4</SU>
                    <FTREF/>
                     thereunder, such that the proposed rule change was immediately effective upon filing with the Commission. The Commission is publishing this notice to solicit comments on the proposed rule change from interested persons.
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         15 U.S.C. 78s(b)(1).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>2</SU>
                         17 CFR 240.19b-4.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>3</SU>
                         15 U.S.C. 78s(b)(3)(A).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>4</SU>
                         17 CFR 240.19b-4(1).
                    </P>
                </FTNT>
                <HD SOURCE="HD1">I. Clearing Agency's Statement of the Terms of Substance of the Proposed Rule Change</HD>
                <P>The principal purpose of the proposed rule change is to revise the ICC Stress Testing Framework (“STF”). These revisions do not require any changes to the ICC Clearing Rules (“Rules”).</P>
                <HD SOURCE="HD1">II. Clearing Agency's Statement of the Purpose of, and Statutory Basis for, the Proposed Rule Change</HD>
                <P>In its filing with the Commission, ICC included statements concerning the purpose of and basis for the proposed rule change, security-based swap submission, or advance notice and discussed any comments it received on the proposed rule change, security-based swap submission, or advance notice. The text of these statements may be examined at the places specified in Item IV below. ICC has prepared summaries, set forth in sections (A), (B), and (C) below, of the most significant aspects of these statements.</P>
                <HD SOURCE="HD2">(A) Clearing Agency's Statement of the Purpose of, and Statutory Basis for, the Proposed Rule Change</HD>
                <HD SOURCE="HD3">(a) Purpose</HD>
                <P>ICC proposes to update the STF. The STF sets forth the ICC stress testing practices that are focused on ensuring the adequacy of systemic risk protections. The proposed changes are limited to clarifying language in Appendix A of the STF. ICC believes the proposed changes will facilitate the prompt and accurate clearance and settlement of securities transactions and derivative agreements, contracts, and transactions for which it is responsible. ICC proposes to move forward with implementation of these changes following Commission approval of the proposed rule change. The proposed changes are described in detail as follows.</P>
                <P>ICC proposes to update STF Section 18, “Appendix A”. Appendix A provides details on the various equations used within the STF. ICC proposes the addition of a cross-reference to the description of Equation 1, Appendix A. Specifically, the descriptive paragraph to Equation 1 contains a reference to “portfolio hypothetical additional losses related to the Wrong Way Risk stemming from Clearing Participant specific exposure.” ICC proposes the addition of a cross-reference to Section 3 of STF which provides additional details regarding “portfolio hypothetical additional losses related to the Wrong Way Risk stemming from Clearing Participant specific exposure.” The proposed addition of the cross-reference does not revise ICC's stress testing methods or procedures, rather it is intended to further clarify the STF as required to address a 2023 Commodity Futures Trading Commission exam finding.</P>
                <P>ICC proposes minor updates to Section 1 `Table of Contents' to update the page numbers. Also, ICC purposes to update the cross-reference coding in Section 7, to footnote 10. Lastly, ICC proposes to update Section 17 `Revision History' to include the proposed changes.</P>
                <HD SOURCE="HD3">(b) Statutory Basis</HD>
                <P>
                    As discussed herein, the proposed addition of the cross-reference to Appendix A in the STF strengthens the STF by clarifying that the language in Appendix A relates to Section 3 of the STF. Accordingly, ICC believes that the 
                    <PRTPAGE P="63455"/>
                    proposed changes to the STF are consistent with the prompt and accurate clearance and settlement of securities transactions, derivatives agreements, contracts, and transactions, the safeguarding of securities and funds in the custody or control of ICC or for which it is responsible, and the protection of investors and the public interest, within the meaning of Section 17(A)(b)(3)(F) of the Act.
                    <SU>5</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>5</SU>
                         17 CFR 240.17(A)(b)(3)(F).
                    </P>
                </FTNT>
                <P>
                    Rule 17Ad-22(e)(4)(vi) 
                    <SU>6</SU>
                    <FTREF/>
                     requires each covered clearing agency to establish, implement, maintain, and enforce written policies and procedures reasonably designed to effectively identify, measure, monitor, and manage its credit exposures to participants and those arising from its payment, clearing, and settlement processes, including by testing the sufficiency of its total financial resources available to meet the minimum financial resource requirements, including by conducting stress testing of its total financial resources once each day using standard predetermined parameters and assumptions; conducting a comprehensive analysis on at least a monthly basis of the existing stress testing scenarios, models, and underlying parameters and assumptions; and reporting the results of its analyses to appropriate decision makers at ICC. The proposed rule change continues to ensure that ICC's policies and procedures, including the STF, provide a clear framework for ICC to conduct stress testing and analysis and report the results to appropriate decision makers at ICC, in compliance with this requirement. As such, ICC believes the proposed rule change is consistent with the requirements of Rule 17Ad-22(e)(4)(vi).
                    <SU>7</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>6</SU>
                         17 CFR 240.17Ad-22(e)(4)(vi).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>7</SU>
                         17 CFR 240.17Ad-22(e)(4)(vi).
                    </P>
                </FTNT>
                <HD SOURCE="HD2">(B) Clearing Agency's Statement on Burden on Competition</HD>
                <P>ICC does not believe the proposed rule change would have any impact, or impose any burden, on competition. The proposed changes to add a cross-reference to the STF, ICC believes are appropriate in furtherance of the risk management of the clearing house. The changes to the STF will apply uniformly across all market participants. ICC does not believe these changes would affect the costs of clearing or the ability of market participants to access clearing. Therefore, ICC does not believe the proposed rule change would impose any burden on competition that is inappropriate in furtherance of the purposes of the Act.</P>
                <HD SOURCE="HD2">(C) Clearing Agency's Statement on Comments on the Proposed Rule Change</HD>
                <P>Written comments relating to the proposed rule change have not been solicited or received. ICC will notify the Commission of any written comments received by ICC.</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) of the Act 
                    <SU>8</SU>
                    <FTREF/>
                     and paragraph (f)(1) of the Rule 19b-4 
                    <SU>9</SU>
                    <FTREF/>
                     thereunder. At any time within 60 days of the filing of the proposed rule change, the Commission summarily may temporarily suspend such rule change if it appears to the Commission that such action is necessary or appropriate in the public interest, for the protection of investors, or otherwise in furtherance of the purposes of the Act.
                </P>
                <FTNT>
                    <P>
                        <SU>8</SU>
                         15 U.S.C. 78s(b)(3)(A).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>9</SU>
                         17 CFR 240.19b-4(f)(1).
                    </P>
                </FTNT>
                <HD SOURCE="HD1">IV. Solicitation of Comments</HD>
                <P>Interested persons are invited to submit written data, views, and arguments concerning the foregoing, including whether the proposed rule change is consistent with the Act. Comments may be submitted by any of the following methods:</P>
                <HD SOURCE="HD2">Electronic Comments</HD>
                <P>
                    • Use the Commission's internet comment form (
                    <E T="03">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-ICC-2024-006 on the subject line.
                </P>
                <HD SOURCE="HD2">Paper Comments</HD>
                <P>• Send paper comments in triplicate to Secretary, Securities and Exchange Commission, 100 F Street NE, Washington, DC 20549.</P>
                <FP>
                    All submissions should refer to file number SR-ICC-2024-006. 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-regulations/self-regulatory-organization-rulemaking</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 such filings will also be available for inspection and copying at the principal office of ICE Clear Credit and on ICE Clear Credit's website at 
                    <E T="03">https://www.theice.com/clear-credit/regulation.</E>
                     Do not include personal identifiable information in submissions; you should submit only information that you wish to make available publicly. We may redact in part or withhold entirely from publication submitted material that is obscene or subject to copyright protection. All submissions should refer to file number SR-ICC-2024-006 and should be submitted on or before August 26, 2024.
                </FP>
                <SIG>
                    <P>
                        For the Commission, by the Division of Trading and Markets, pursuant to delegated authority.
                        <SU>10</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>10</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-17146 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 8011-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">SECURITIES AND EXCHANGE COMMISSION</AGENCY>
                <SUBJECT>Sunshine Act Meetings</SUBJECT>
                <PREAMHD>
                    <HD SOURCE="HED">TIME AND DATE: </HD>
                    <P>2:00 p.m. on Thursday, August 8, 2024.</P>
                </PREAMHD>
                <PREAMHD>
                    <HD SOURCE="HED">PLACE: </HD>
                    <P>The meeting will be held via remote means and/or at the Commission's headquarters, 100 F Street NE, Washington, DC 20549.</P>
                </PREAMHD>
                <PREAMHD>
                    <HD SOURCE="HED">STATUS: </HD>
                    <P>This meeting will be closed to the public.</P>
                </PREAMHD>
                <PREAMHD>
                    <HD SOURCE="HED">MATTERS TO BE CONSIDERED: </HD>
                    <P>Commissioners, Counsel to the Commissioners, the Secretary to the Commission, and recording secretaries will attend the closed meeting. Certain staff members who have an interest in the matters also may be present.</P>
                    <P>
                        In the event that the time, date, or location of this meeting changes, an announcement of the change, along with the new time, date, and/or place of the meeting will be posted on the Commission's website at 
                        <E T="03">https://www.sec.gov.</E>
                    </P>
                    <P>
                        The General Counsel of the Commission, or her designee, has certified that, in her opinion, one or more of the exemptions set forth in 5 
                        <PRTPAGE P="63456"/>
                        U.S.C. 552b(c)(3), (5), (6), (7), (8), 9(B) and (10) and 17 CFR 200.402(a)(3), (a)(5), (a)(6), (a)(7), (a)(8), (a)(9)(ii) and (a)(10), permit consideration of the scheduled matters at the closed meeting.
                    </P>
                    <P>The subject matter of the closed meeting will consist of the following topics:</P>
                    <P>Institution and settlement of injunctive actions;</P>
                    <P>Institution and settlement of administrative proceedings;</P>
                    <P>Resolution of litigation claims; and</P>
                    <P>Other matters relating to examinations and enforcement proceedings.</P>
                    <P>At times, changes in Commission priorities require alterations in the scheduling of meeting agenda items that may consist of adjudicatory, examination, litigation, or regulatory matters.</P>
                </PREAMHD>
                <PREAMHD>
                    <HD SOURCE="HED">CONTACT PERSON FOR MORE INFORMATION: </HD>
                    <P>For further information, please contact Vanessa A. Countryman from the Office of the Secretary at (202) 551-5400.</P>
                    <P>
                        <E T="03">Authority:</E>
                         5 U.S.C. 552b.
                    </P>
                </PREAMHD>
                <SIG>
                    <DATED>Dated: August 1, 2024.</DATED>
                    <NAME>J. Matthew DeLesDernier,</NAME>
                    <TITLE>Deputy Secretary.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2024-17348 Filed 8-1-24; 4:15 pm]</FRDOC>
            <BILCOD>BILLING CODE 8011-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">SMALL BUSINESS ADMINISTRATION</AGENCY>
                <DEPDOC>[Disaster Declaration #20443 and #20444; MINNESOTA Disaster Number MN-20004]</DEPDOC>
                <SUBJECT>Presidential Declaration of a Major Disaster for the State of Minnesota</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>U.S. Small Business Administration.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>This is a Notice of the Presidential declaration of a major disaster for the State of Minnesota (FEMA-4797-DR), dated 07/29/2024.</P>
                    <P>
                        <E T="03">Incident:</E>
                         Severe Storms and Flooding.
                    </P>
                    <P>
                        <E T="03">Incident Period:</E>
                         06/16/2024 through 07/04/2024.
                    </P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Issued on 07/29/2024.</P>
                    <P>
                        <E T="03">Physical Loan Application Deadline Date:</E>
                         09/30/2024.
                    </P>
                    <P>
                        <E T="03">Economic Injury (EIDL) Loan Application Deadline Date:</E>
                         04/29/2025.
                    </P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        <E T="03">Visit the MySBA Loan Portal at https://lending.sba.gov</E>
                         to apply for a disaster assistance loan.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Alan Escobar, Office of Disaster Recovery &amp; Resilience, U.S. Small Business Administration, 409 3rd Street SW, Suite 6050, Washington, DC 20416, (202) 205-6734.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    Notice is hereby given that as a result of the President's major disaster declaration on 07/29/2024, applications for disaster loans may be submitted online using the MySBA Loan Portal 
                    <E T="03">https://lending.sba.gov</E>
                     or other locally announced locations. Please contact the SBA disaster assistance customer service center by email at 
                    <E T="03">disastercustomerservice@sba.gov</E>
                     or by phone at 1-800-659-2955 for further assistance.
                </P>
                <P>The following areas have been determined to be adversely affected by the disaster:</P>
                <FP SOURCE="FP-2">
                    <E T="03">Primary Counties (Physical Damage and Economic Injury Loans):</E>
                     Blue Earth, Cook, Cottonwood, Faribault, Freeborn, Goodhue, Itasca, Jackson, Lake, Le Sueur, Mower, Nicollet, Nobles, Rice, Rock, St. Louis, Steele, Waseca, Watonwan.
                </FP>
                <FP SOURCE="FP-2">
                    <E T="03">Contiguous Counties (Economic Injury Loans Only):</E>
                </FP>
                <FP SOURCE="FP1-2">Minnesota: Aitkin, Beltrami, Brown, Carlton, Cass, Dakota, Dodge, Fillmore, Koochiching, Martin, Murray, Olmsted, Pipestone, Redwood, Renville, Scott, Sibley, Wabasha.</FP>
                <FP SOURCE="FP1-2">Iowa: Dickinson, Emmet, Howard, Kossuth, Lyon, Mitchell, Osceola, Winnebago, Worth.</FP>
                <FP SOURCE="FP1-2">South Dakota: Minnehaha, Moody.</FP>
                <FP SOURCE="FP1-2">Wisconsin: Douglas, Pepin, Pierce.</FP>
                <P>The Interest Rates are:</P>
                <GPOTABLE COLS="2" OPTS="L2,nj,tp0,i1" CDEF="s25,8">
                    <TTITLE> </TTITLE>
                    <BOXHD>
                        <CHED H="1"> </CHED>
                        <CHED H="1">Percent</CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="22">
                            <E T="03">For Physical Damage:</E>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="02">Homeowners with Credit Available Elsewhere</ENT>
                        <ENT>5.375</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="02">Homeowners without Credit Available Elsewhere</ENT>
                        <ENT>2.688</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="02">Businesses with Credit Available Elsewhere</ENT>
                        <ENT>8.000</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="02">Businesses without Credit Available Elsewhere</ENT>
                        <ENT>4.000</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="02">Non-Profit Organizations with Credit Available Elsewhere</ENT>
                        <ENT>3.250</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="02">Non-Profit Organizations without Credit Available Elsewhere</ENT>
                        <ENT>3.250</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22">
                            <E T="03">For Economic Injury:</E>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="02">Business and Small Agricultural Cooperatives without Credit Available Elsewhere</ENT>
                        <ENT>4.000</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="02">Non-Profit Organizations without Credit Available Elsewhere</ENT>
                        <ENT>3.250</ENT>
                    </ROW>
                </GPOTABLE>
                <P>The number assigned to this disaster for physical damage is 204436 and for economic injury is 204440.</P>
                <EXTRACT>
                    <FP>(Catalog of Federal Domestic Assistance Number 59008)</FP>
                </EXTRACT>
                <SIG>
                    <NAME>Rafaela Monchek,</NAME>
                    <TITLE>Deputy Associate Administrator, Office of Disaster Recovery &amp; Resilience.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17193 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 8026-09-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">SMALL BUSINESS ADMINISTRATION</AGENCY>
                <DEPDOC>[Disaster Declaration #20466 and #20467; KANSAS Disaster Number KS-20012]</DEPDOC>
                <SUBJECT>Presidential Declaration Amendment of a Major Disaster for Public Assistance Only for the State of Kansas</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>U.S. Small Business Administration.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Amendment 1.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>This is an amendment of the Presidential declaration of a major disaster for Public Assistance Only for the State of Kansas (FEMA-4800-DR), dated 07/15/2024.</P>
                    <P>
                        <E T="03">Incident:</E>
                         Severe Storms, Straight-line Winds, Tornadoes, and Flooding.
                    </P>
                    <P>
                        <E T="03">Incident Period:</E>
                         04/25/2024 through 04/30/2024.
                    </P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Issued on 07/29/2024.</P>
                    <P>
                        <E T="03">Physical Loan Application Deadline Date:</E>
                         09/13/2024.
                    </P>
                    <P>
                        <E T="03">Economic Injury (EIDL) Loan Application Deadline Date:</E>
                         04/15/2025.
                    </P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        <E T="03">Visit the MySBA Loan Portal at https://lending.sba.gov</E>
                         to apply for a disaster assistance loan.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Vanessa Morgan, Office of Disaster Recovery &amp; Resilience, U.S. Small Business Administration, 409 3rd Street SW, Suite 6050, Washington, DC 20416, (202) 205-6734.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>The notice of the President's major disaster declaration for Private Non-Profit organizations in the State of Kansas, dated 07/15/2024, is hereby amended to include the following areas as adversely affected by the disaster.</P>
                <FP SOURCE="FP-2">
                    <E T="03">Primary Counties:</E>
                </FP>
                <FP SOURCE="FP1-2">Woodson.</FP>
                <P>All other information in the original declaration remains unchanged.</P>
                <EXTRACT>
                    <FP>(Catalog of Federal Domestic Assistance Number 59008)</FP>
                </EXTRACT>
                <SIG>
                    <NAME>Rafaela Monchek,</NAME>
                    <TITLE>Deputy Associate Administrator, Office of Disaster Recovery &amp; Resilience.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17194 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 8026-09-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">DEPARTMENT of STATE</AGENCY>
                <DEPDOC>[Public Notice: 12480]</DEPDOC>
                <SUBJECT>Proposed Establishment of a Federally Funded Research and Development Center—Second Notice</SUBJECT>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>
                        The United States Department of State (DoS), Bureau of 
                        <PRTPAGE P="63457"/>
                        Administration, intends to sponsor a Federally Funded Research and Development Center (FFRDC) to facilitate public-private collaboration for numerous activities related to diplomacy and modernization. This is the second of three notices which must be published over a 90-day period in order to advise the public of the agency's intention to sponsor an FFRDC.
                    </P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Written comments must be received by 5:00 p.m. Eastern time on August 15, 2024.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>Please send any comments, identified by title of the action and Regulatory Information Number (RIN) by any of the following methods:</P>
                    <P>
                         Through the Federal eRulemaking Portal at 
                        <E T="03">www.regulations.gov</E>
                         and search for nonrulemaking docket [DOS-2024-0021].
                    </P>
                    <P>
                          
                        <E T="03">By email:</E>
                         Submit electronic comments to 
                        <E T="03">FFRDC@state.gov.</E>
                    </P>
                    <P>
                         The summary of this rule can be found at 
                        <E T="03">www.regulations.gov/document/DOS-2024-0021.</E>
                    </P>
                </ADD>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>The Department of State leads US engagement around the world building alliances and partnerships; facing up to aggression; aiding and supporting emerging democracies; and preserving U.S. interests abroad. In a rapidly changing world with shifting politics, accelerated economic developments, global challenges such as climate change, and the increasing role digitization plays for both opportunity and threats, the Department is committed to leading through both policy and operational engagement on behalf of the nation and our government.</P>
                <P>In a letter introducing the Department of State and U.S. Agency for International Development Joint Strategic Plan for 2022-2026, Secretary Blinken stated, “we are working to modernize and equip the Department and USAID to lead on 21st-Century challenges and deliver for the American people.”</P>
                <P>Achieving U.S. goals for global leadership over the next decade will require the following:</P>
                <P>• A diplomatic corps to use data in new ways to develop more foresight and insight, to inform policy options, to take actions and measure their effectiveness;</P>
                <P>• New cross-sector partnerships and coalitions;</P>
                <P>
                    • Intergovernmental partnerships with the Department of Defense, the intelligence agencies, the Departments of Commerce, Treasury, Homeland Security, and Health and Human Services, and cross-government Councils (
                    <E T="03">e.g.,</E>
                     National Economic Council, National Security Council);
                </P>
                <P>• New capabilities to plan, manage and execute initiatives and programs;</P>
                <P>• A workforce that uses digital technology as tools to advance democracy and protect our interests and counter the use of these same technologies as a threat; and</P>
                <P>• An organization and operation that is agile and adaptive to a changing environment; attractive to new talent; and fosters long-term commitment between the organization and its people.</P>
                <P>The Department requires long-term partnerships with organizations that can bring research, development, innovation, and support needed to guide the leadership and employees through this transformative period in our history. This will allow the Department to focus on the mission at hand, while adopting and integrating changes necessary to make consistent progress on these goals and surge, when needed, to address urgent issues that require data, partnerships, technology and insights applied in near-term operational situations.</P>
                <P>To meet this need, the Department seeks to establish and sponsor one (1) FFRDC under the authority of 48 CFR 35.017.</P>
                <HD SOURCE="HD1">FFRDC Center</HD>
                <P>
                    The FFRDC will be available to provide a wide range of support including, but not limited to the activities under three focus areas delineated below. The Department anticipates that the focus areas below will be managed as a single-award FFRDC. This strategy and focus area list have been updated since the first 
                    <E T="04">Federal Register</E>
                     notice published on May 17, 2024:
                </P>
                <FP SOURCE="FP-1">• Diplomatic Innovation and Modernization (DIM)</FP>
                <P>The purpose of the DIM focus area is to strengthen global engagement and humanitarian outcomes by pioneering research and development initiatives that address emerging threats and foster international cooperation.</P>
                <FP SOURCE="FP-1">• Global CyberTech Solutions (GCS)</FP>
                <P>The purpose of the GCS focus area is to enhance global stability through cutting edge research and development in IT, cyber defense, systems engineering, and data analytics.</P>
                <P>• Global Operations and Acquisitions (GOA)</P>
                <P>The purpose of the GOA focus area is to advance diplomatic effectiveness through collaborative and cutting-edge acquisition methodologies and tools, and data assessments of broad scale Department needs, international cooperation, and innovative operational practices.</P>
                <P>The FFRDC will partner with the Department of State in the design and pursuit of mission goals; provide rapid responsiveness to changing requirements for personnel in all aspects of strategic, technical and program management; recognize Government objectives as its own objectives, partner in pursuit of excellence in public service; and allow for use of the FFRDC by non-sponsors.</P>
                <P>The Department is publishing this notice in accordance with 48 CFR 5.205(b) of the Federal Acquisition Regulations (FAR) to enable interested members of the public to provide comments on this proposed action. This is the second of three notices issued under the authority of 48 CFR 5.205(b).</P>
                <HD SOURCE="HD1">Information Requested</HD>
                <P>In particular, we are interested in feedback regarding the proposed focus areas to be performed under the FFRDC, and the presence of any existing private- or public-sector capabilities in these areas that the Department should be considering.</P>
                <P>The Department anticipates releasing the final RFP in calendar year 2024.</P>
                <HD SOURCE="HD1">Public Comments</HD>
                <P>Since the first notice, the Department has received the following comments/questions and is hereby providing the following responses:</P>
                <P>The Department received ten comments on the first notice.</P>
                <P>
                    Six of these expressed interest in submitting responses, capabilities, or eventually proposals for the FFRDC. The Department appreciates the interest and looks forward to receiving further comments/questions and submissions in response to the eventual RFP. While the Department is not taking meetings at this time, all interested parties should continue to monitor for the third 
                    <E T="04">Federal Register</E>
                     notice to receive more information about the upcoming acquisition actions and industry engagement activities.
                </P>
                <P>One comment questioned whether this initiative would expand the State Department and its budget. At this time, the FFRDC is intended to provide long-term research and development in areas that the State Department is already exploring in other capacities and projects are intended to be funded through the Department's existing appropriated or other types of funds. The Department plans to initially provide oversight for the FFRDC by leveraging the existing Procurement Shared Services Working Capital Fund.</P>
                <P>
                    Another comment identified climate and sustainability research as a potential focus area, which the 
                    <PRTPAGE P="63458"/>
                    Department already plans to include under the “Emerging Threats” topic in the DIM focus area. This commenter also identified cybersecurity tracking and decryption techniques as well as telecommunications as areas for inclusion in the GCS focus area; however, this comment focused on stricter penalties and increased law enforcement and regulations, which is outside the scope of the Department's research and development requirements.
                </P>
                <P>One comment suggested moving the “Systems Engineering, System Architecture and Integration” work elements from the “Information Technology and Cyber Operations FFRDC” to the “Emerging Threats, Concept Exploration, Experimentation and Evaluation” FFRDC. However, as a result of internal comments and requirements definitions, the focus areas have all been merged into one FFRDC, which makes this comment moot.</P>
                <P>The final comment stated that the focus on technology duplicates existing bureaus' portfolios and requested a focus area on organizational development challenges; however, this focus area would fall under the GOA focus area and does not negate the need for long-term IT research and development activities that foster data and collaboration across the agency.</P>
                <SIG>
                    <NAME>Michael W. Derrios,</NAME>
                    <TITLE>Deputy Assistant Secretary for Acquisition, &amp; Senior Procurement Executive, Department of State.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17213 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4710-24-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">SURFACE TRANSPORTATION BOARD</AGENCY>
                <DEPDOC>[Docket No. FD 36764 (Sub-No. 1)]</DEPDOC>
                <SUBJECT>Great Lakes Terminal Railroad, LLC—Acquisition and Operation Exemption—Great Lakes Terminal, LLC, CRRC Sifang America Incorporated, and Chicago Enterprise Owners' Association</SUBJECT>
                <P>On May 2, 2024, Great Lakes Terminal Railroad, LLC (GLTRR), a Class III carrier, filed for an exemption under 49 U.S.C. 10502 from the provisions of 49 U.S.C. 10902 for after-the-fact authorization to acquire and operate approximately 22,568 feet of track in Chicago, Ill., owned by Great Lakes Terminal, LLC (GLT), CRRC Sifang America Incorporated (CRRC), and Chicago Enterprise Center Owners' Association (Owners' Association). For the reasons explained below, the Board will grant GLTRR's petition.</P>
                <HD SOURCE="HD1">Background</HD>
                <P>
                    GLTRR's petition seeks after-the-fact authority for the acquisition and operation of 22,568 feet of track (the Line) located in and adjacent to a transloading facility at 13535 South Torrence Avenue in Chicago (the Facility). GLTRR states that ownership of the Line is divided between GLT 
                    <SU>1</SU>
                    <FTREF/>
                     (owning 14,215 feet of track inside the Facility), CRRC (owning 850 feet of track outside the Facility), and the Owners' Association (owning 7,503 feet of track outside the Facility). (GLTRR Petition 3, 6 &amp; n.11.) According to GLTRR, it previously operated over 12,500 feet of track that is now part of the Line that was owned by CenterPoint Chicago Enterprise, LLC (CenterPoint), leased to Great Lakes Reloading LLC (GLR), an affiliate of GLTRR, and operated by GLTRR under a sublease between GLTRR and GLR. GLTRR Notice 4 &amp; n.5, 
                    <E T="03">Great Lakes Terminal R.R.—Acquis. &amp; Operation Exemption—Norfolk S. Ry.,</E>
                     FD 36764. GLTRR's authority to operate those 12,500 feet of track under the sublease with GLR was obtained through a notice of exemption. 
                    <E T="03">See Great Lakes Terminal R.R.—Lease &amp; Operation Exemption—Rail Line of Great Lake Reloading, LLC</E>
                     (
                    <E T="03">January 5, 2018 Decision</E>
                    ), FD 36160 (STB served Jan. 5, 2018). GLTRR asserts that a few months after the 
                    <E T="03">January 5, 2018 Decision,</E>
                     in April 2018, GLT acquired a fee simple interest in the Facility from CenterPoint, including the portion of the Line inside the Facility, and that as part of that transaction, GLT obtained rights held by CenterPoint allowing it to conduct rail operations over the Owners' Association's and CRRC's tracks.
                    <SU>2</SU>
                    <FTREF/>
                     (GLTRR Pet. 6.) GLTRR further states that in April 2018, soon after GLT's acquisition of these rights and the fee simple interest in the Facility, GLT entered into an agreement (2018 Agreement) with GLTRR to lease GLTRR the track it acquired from CenterPoint and to assign to GLTRR the rights to conduct rail operations over CRRC's and the Owners' Association's tracks. (
                    <E T="03">Id.</E>
                     at 6, 10.) As GLTRR explains, it did not seek Board authority to enter into the 2018 Agreement. (
                    <E T="03">Id.</E>
                     at 6-7.) GLTRR claims that it did not seek authority for the 2018 Agreement at that time based on a mistaken belief that no additional authority was needed because it had just received Board authority to operate at the Facility under a sublease with GLT in Docket No. FD 36160 and would continue to operate at the Facility. (
                    <E T="03">See id.</E>
                     at 5.)
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         GLT is an affiliate of GLTRR, both of which are owned by the Transload Group, LLC.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>2</SU>
                         GLTRR states that CenterPoint obtained the right to conduct rail operations on the Owners' Association's property pursuant to a March 23, 2018 declaration and obtained an easement to conduct rail operations over CRRC's property pursuant to an August 2017 easement.
                    </P>
                </FTNT>
                <P>
                    Prior to GLTRR filing its petition, it filed a notice of exemption stating that GLT planned to sell its portion of the Line to Norfolk Southern Railway (NSR) and that GLTRR would then lease that portion of the Line from NSR and continue to operate as it does today. GLTRR Notice 5, 
                    <E T="03">Great Lakes Terminal R.R.—Acquis. &amp; Operation Exemption—Norfolk S. Ry.,</E>
                     FD 36764. The verified notice sought Board authority to enter into the lease with NSR and to continue to operate over the track that would be sold to NSR, as well as the track that would continue to be owned by CRRC and the Owners' Association. 
                    <E T="03">Id.</E>
                     In that verified notice, GLTRR also explained its previous failure to seek authority for GLTRR's 2018 acquisition by lease and operation of GLT's tracks and requested that the Board grant, “on its own motion,” after-the-fact authority for that transaction. 
                    <E T="03">Id.</E>
                     at 4-5.
                </P>
                <P>
                    The verified notice was rejected on the grounds that this case was not appropriate for the notice of exemption process, which is designed for routine cases that do not raise issues requiring significant scrutiny. 
                    <E T="03">Great Lakes Terminal R.R.—Acquis. &amp; Operation Exemption—Norfolk S. Ry.</E>
                     (
                    <E T="03">Director Order</E>
                    ), FD 36764, slip op. at 2-3 (STB served Apr. 26, 2024). The 
                    <E T="03">Director Order</E>
                     explained that use of a notice of exemption to seek after-the-fact authority for a prior transaction that is not the subject of the notice is not routine. 
                    <E T="03">Id.</E>
                     at 2. The 
                    <E T="03">Director Order</E>
                     further stated that the verified notice had raised unanswered questions regarding whether GLTRR should have also sought Board authority to enter into agreements with CRRC and the Owners' Association to operate over their tracks. 
                    <E T="03">Id.</E>
                     at 2-3. The Board ordered GLTRR to file a petition for exemption for after-the-fact authority for the prior acquisition and operation of GLT's tracks and to file a petition for exemption for after-the-fact authority for the acquisition and operation of CRRC's and the Owners' Association's tracks or to explain why such authority is not required. 
                    <E T="03">Id.</E>
                     at 3.
                    <SU>3</SU>
                    <FTREF/>
                     As explained below, GLTRR's petition adequately addresses the questions raised by the Board and otherwise provides information sufficient to grant its petition.
                    <SU>4</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>3</SU>
                         The 
                        <E T="03">Director Order</E>
                         further stated that once GLTRR obtains all necessary after-the-fact authority for prior transactions, it can proceed with a notice of exemption for its proposed lease with NSR. 
                        <E T="03">Id.</E>
                         at 3.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>4</SU>
                         GLTRR requested expedited consideration of its petition. (GLTRR Pet. 4.) On July 12, 2024, GLTRR 
                        <PRTPAGE/>
                        filed a letter renewing its request for expedited consideration.
                    </P>
                </FTNT>
                <PRTPAGE P="63459"/>
                <P>
                    GLTRR's verified notice failed to explain why GLTRR had never requested authority for agreements pursuant to which it operated over the Owners' Association's and CRRC's tracks. 
                    <E T="03">Director Order,</E>
                     FD 36764, slip op. at 3. Rather, GLTRR only stated that at some point after the 
                    <E T="03">January 5, 2018 Decision</E>
                     authorized GLTRR to operate 12,500 feet of track at the Facility, “additional trackage was added,” and that GLTRR now operates over 22,568 feet of track, including the track owned by the Owners' Association and CRRC. 
                    <E T="03">Id.</E>
                     at 2. In its petition, GLTRR clarifies that its agreement to lease the track GLT acquired from CenterPoint also included an assignment to GLTRR of the rights GLT acquired from CenterPoint to operate over track owned by CRRC and the Owner's Association.
                    <SU>5</SU>
                    <FTREF/>
                     (GLTRR Pet. 5-6.) For the reasons explained below, the Board will grant GLTRR's petition for exemption for after-the-fact authority for the Line.
                </P>
                <FTNT>
                    <P>
                        <SU>5</SU>
                         The 
                        <E T="03">Director Order</E>
                         also noted GLTRR's statement that “today GLTRR is leasing 14,215 linear feet (2.69 miles) of trackage from NSR and will continue to operate over [it],” and explained that “[t]his language suggests that GLT has already sold the track to NSR and GLTRR has entered into a lease with NSR without the necessary Board authority.” 
                        <E T="03">Director Order,</E>
                         FD 36764, slip op. at 3. GLTRR's petition explains that the language quoted by the Board contained a typo and should have referred to GLT rather than NSR as the party currently leasing the track to GLTRR, and that NSR has not yet purchased GLT's track or consummated a lease with GLTRR. (GLTRR Pet. 7.)
                    </P>
                </FTNT>
                <P>The acquisition of a rail line by a Class III carrier requires prior approval from the Board under 49 U.S.C. 10902(a). Under 49 U.S.C. 10502(a), however, the Board shall, to the maximum extent consistent with U.S. Code Title 49, subtitle IV, part A, exempt a transaction from the detailed application procedures of 49 U.S.C. 10902 when it finds that: (1) those procedures are not necessary to carry out the rail transportation policy of 49 U.S.C. 10101 (RTP); and (2) either (a) the proposal is of limited scope, or (b) the full application procedures are not necessary to protect shippers from an abuse of market power.</P>
                <P>
                    The Board finds an after-the-fact exemption should be granted to GLTRR for its acquisition and operation of the Line pursuant to the 2018 Agreement. Prior to the 2018 Agreement, in January 2018, GLTRR sought and obtained authority to sublease from GLR and operate track at the Facility. 
                    <E T="03">See January 5, 2018 Decision,</E>
                     FD 36160. A few months later, the Facility was sold to GLT and GLTRR entered into the 2018 Agreement so that it could continue its operations at that facility after the change in ownership.
                    <SU>6</SU>
                    <FTREF/>
                     (
                    <E T="03">See</E>
                     GLTRR Pet. 5.) GLTRR states that it failed to seek authority for the 2018 Agreement and subsequent operations because it mistakenly believed that the authority it obtained in January 2018 to operate pursuant to an agreement with one of its affiliates, GLR, was sufficient to allow it to continue to operate at the Facility pursuant to an agreement with another of its affiliates, GLT. (
                    <E T="03">Id.</E>
                    ) Based on the nature of the transaction at issue and the inadvertent nature of the failure to seek an exemption prior to completing the transaction, an exemption from the prior approval requirements of section 10902 is consistent with section 10502(a) and detailed scrutiny of the transaction through an application for review under 49 U.S.C. 10902 is not necessary here to carry out the RTP.
                    <SU>7</SU>
                    <FTREF/>
                     Granting an exemption to correct GLTRR's past error so that it is authorized to continue operations at the Facility and can proceed to file a notice of exemption for its proposed transaction with NSR would promote the RTP by minimizing the need for regulatory control over the transaction (49 U.S.C. 10101(2)), ensuring the development and continuation of a sound rail transportation system able to compete with other modes of transportation and meet the needs of the public (49 U.S.C. 10101(4)), minimizing the need for regulatory barriers for entry into and exit from the industry (49 U.S.C. 10101(7)), and providing for the expeditious handling and resolution of proceedings required or permitted to be brought under this part (49 U.S.C. 10101(15)). Other aspects of the RTP will not be adversely affected.
                </P>
                <FTNT>
                    <P>
                        <SU>6</SU>
                         As noted above, the 2018 Agreement also allowed GLTRR to operate over additional trackage immediately outside the Facility owned by the Owners' Association and CRRC.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>7</SU>
                         The Board has granted after-the-fact authority in similar circumstances. 
                        <E T="03">See Ark.-Okla. R.R.—Acquis. &amp; Operation Exemption—Okla.,</E>
                         FD 36323 (STB served Sept. 19, 2019) (granting an exemption for after-the-fact authority where a carrier was previously authorized by the Board to operate a rail line pursuant to a lease but mistakenly believed it did not require additional authority to exercise a purchase option and continue its operations as owner of the line); 
                        <E T="03">Elk River R.R.—Merger Exemption—Buffalo Creek R.R.,</E>
                         FD 36434 (STB served Nov. 6, 2020) (granting an exemption for after-the-fact authority where a rail carrier authorized by the Board to operate mistakenly believed it did not need additional authority to merge with its affiliate and for the surviving entity to continue operations post-merger).
                    </P>
                </FTNT>
                <P>
                    Regulation of the transaction is not needed to protect shippers from an abuse of market power. GLTRR states that both before and after the 2018 Agreement, its operations consisted of providing transloading services to shippers seeking to ship steel rebar and steel piping by truck after arrival at the Facility by rail, as well as agriculture and construction equipment by rail after arrival at the Facility by truck. (GLTRR Pet. 10.) Granting the requested exemption for after-the-fact authority would give GLTRR authority to provide these same services to shippers that it has been providing since 2018.
                    <SU>8</SU>
                    <FTREF/>
                     In addition, and as GLTRR contends, there was no apparent loss of rail competition and no change in the level of rail service to the shippers as a result of the 2018 Agreement.
                </P>
                <FTNT>
                    <P>
                        <SU>8</SU>
                         Because regulation of the proposed acquisition and operation is not needed to protect shippers from the abuse of market power, the Board need not determine whether the transaction is limited in scope. 49 U.S.C. 10502(a)(2).
                    </P>
                </FTNT>
                <P>Under 49 CFR 1105.6(c)(1), this action, which will not result in significant changes in carrier operations, is categorically excluded from environmental review. Similarly, under 49 CFR 1105.8(b)(1), no historic report is required because the subject transaction is for continued rail service, GLT does not intend to dispose of or alter properties subject to the Board's jurisdiction that are 50 years old or older, (GLTRR Pet. 14), and discontinuance of service or abandonment by GLTRR would be subject to Board jurisdiction.</P>
                <P>
                    <E T="03">It is ordered:</E>
                </P>
                <P>1. Under 49 U.S.C. 10502, the Board grants GLTRR's petition for exemption for after-the-fact authority to acquire and operate the Line.</P>
                <P>
                    2. Notice of this exemption will be published in the 
                    <E T="04">Federal Register</E>
                    .
                </P>
                <P>3. This decision will be effective on August 30, 2024. Petitions for stay must be filed by August 12, 2024. Petitions to reopen must be filed by August 20, 2024.</P>
                <SIG>
                    <DATED>Decided: July 30, 2024.</DATED>
                    <P>By the Board, By the Board, Board Members Fuchs, Hedlund, Primus, and Schultz.</P>
                    <NAME>Eden Besera,</NAME>
                    <TITLE>Clearance Clerk.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2024-17187 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4915-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">SURFACE TRANSPORTATION BOARD</AGENCY>
                <SUBJECT>60-Day Notice of Intent To Seek Extension of Approval of Collections: Rail Carrier Financial Reports</SUBJECT>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice and request for comments.</P>
                </ACT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Surface Transportation Board.</P>
                </AGY>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>
                        As part of its continuing effort to reduce paperwork burdens, and as required by the Paperwork Reduction Act of 1995 (PRA), the Surface 
                        <PRTPAGE P="63460"/>
                        Transportation Board (Board) gives notice of its intent to request from the Office of Management and Budget (OMB) approval without change of the six existing collections described below.
                    </P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Comments on these information collections should be submitted by October 4, 2024.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Direct all comments to Chris Oehrle, PRA Officer, Surface Transportation Board, 395 E Street SW, Washington, DC 20423-0001, or to 
                        <E T="03">PRA@stb.gov.</E>
                         When submitting comments, please refer to “Paperwork Reduction Act Comments, Rail Carrier Financial Reports.” For further information regarding these collections, contact Pedro Ramirez at (202) 245-0333 or 
                        <E T="03">pedro.ramirez@stb.gov.</E>
                         If you require an accommodation under the Americans with Disabilities Act, please call (202) 245-0245.
                    </P>
                </ADD>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>Comments are requested concerning each collection as to (1) whether the particular collection of information is necessary for the proper performance of the functions of the Board, including whether the collection has practical utility; (2) the accuracy of the Board's burden estimates; (3) ways to enhance the quality, utility, and clarity of the information collected; and (4) ways to minimize the burden of the collection of information on the respondents, including the use of automated collection techniques or other forms of information technology, when appropriate. Submitted comments will be included and summarized in the Board's request for OMB approval.</P>
                <P>
                    <E T="03">Subjects:</E>
                     In this notice, the Board is requesting comments on the following information collections:
                </P>
                <HD SOURCE="HD1">Description of Collection 1</HD>
                <P>
                    <E T="03">Title:</E>
                     Quarterly Report of Freight Commodity Statistics (Form QCS).
                </P>
                <P>
                    <E T="03">OMB Control Number:</E>
                     2140-0001.
                </P>
                <P>
                    <E T="03">Form Number:</E>
                     Form QCS.
                </P>
                <P>
                    <E T="03">Type of Review:</E>
                     Extension without change.
                </P>
                <P>
                    <E T="03">Respondents:</E>
                     Class I railroads.
                </P>
                <P>
                    <E T="03">Number of Respondents:</E>
                     Seven.
                </P>
                <P>
                    <E T="03">Estimated Time per Response:</E>
                     One hour.
                </P>
                <P>
                    <E T="03">Frequency of Response:</E>
                     Quarterly, with an annual summation.
                </P>
                <P>
                    <E T="03">Total Annual Hour Burden:</E>
                     35 hours annually.
                </P>
                <P>
                    <E T="03">Total Annual “Non-Hour Burden” Cost:</E>
                     None identified. Filings are submitted electronically to the Board.
                </P>
                <P>
                    <E T="03">Needs and Uses:</E>
                     This collection, which is based on information contained in carload waybills used by railroads in the ordinary course of business, reports car loadings and total revenues by commodity code for each commodity that moved on the railroad during the reporting period. 
                    <E T="03">See</E>
                     49 CFR part 1248. Information reported on Form QCS is entered into the Agency's Uniform Rail Costing System (URCS). URCS, which was developed by the Board pursuant to 49 U.S.C. 11161-62, is used in rail rate proceedings as a tool to calculate the variable costs of providing a particular rail service in accordance with 49 U.S.C. 10707(d). The Form QCS has been reformatted in a way that should allow for more efficient submission and agency processing, but it contains all of the same information as required. This collection is compiled and published on the Board's website, 
                    <E T="03">https://www.stb.gov/stb/industry/econ_reports.html.</E>
                     The reformatted form and instructions may be viewed at 
                    <E T="03">https://www.stb.gov/wp-content/uploads/Quarterly-and-Annual-Freight-Commodity-Statistics-Public.xlsx</E>
                     and 
                    <E T="03">https://www.stb.gov/wp-content/uploads/Instructions-for-Quarterly-and-Annual-Freight-Commodity-Statistics.pdf,</E>
                     respectively. It should be noted that the form for this report has been reformatted in a way that should allow for more efficient submission and agency processing, but the information has not changed. The form continues to contain all of the same data elements. The information contained in this report is not available from any other source.
                </P>
                <HD SOURCE="HD1">Description of Collection 2</HD>
                <P>
                    <E T="03">Title:</E>
                     Report of Railroad Employees, Service and Compensation (Wage Forms A and B).
                </P>
                <P>
                    <E T="03">OMB Control Number:</E>
                     2140-0004.
                </P>
                <P>
                    <E T="03">Form Number:</E>
                     Wage Form A; and Wage Form B.
                </P>
                <P>
                    <E T="03">Type of Review:</E>
                     Extension without change.
                </P>
                <P>
                    <E T="03">Respondents:</E>
                     Class I railroads.
                </P>
                <P>
                    <E T="03">Number of Respondents:</E>
                     Seven.
                </P>
                <P>
                    <E T="03">Estimated Time per Response:</E>
                     No more than 3 hours per quarterly report and 4 hours per annual summation.
                </P>
                <P>
                    <E T="03">Frequency of Response:</E>
                     Quarterly, with an annual summation.
                </P>
                <P>
                    <E T="03">Total Annual Hour Burden:</E>
                     No more than 112 hours annually.
                </P>
                <P>
                    <E T="03">Total Annual “Non-Hour Burden” Cost:</E>
                     None identified. Filings are submitted electronically to the Board.
                </P>
                <P>
                    <E T="03">Needs and Uses:</E>
                     This collection shows the number of employees, service hours, and compensation, by employee group (
                    <E T="03">e.g.,</E>
                     executive, professional, maintenance-of-way and equipment, and transportation), of the reporting railroads. 
                    <E T="03">See</E>
                     49 CFR part 1245. The information is used by the Board to forecast labor costs and measure the efficiency of the reporting railroads. The information is also used by the Board to evaluate proposed regulated transactions that may impact rail employees, including mergers and consolidations, acquisitions of control, purchases, and abandonments. Other Federal agencies and industry groups, including the Railroad Retirement Board (RRB), Bureau of Labor Statistics (BLS), and Association of American Railroads (AAR), use the information contained in the reports to monitor railroad operations. Certain information from these reports is compiled and published on the Board's website, 
                    <E T="03">https://www.stb.gov/stb/industry/econ_reports.html.</E>
                     The reformatted forms and instructions may be viewed at 
                    <E T="03">https://www.stb.gov/wp-content/uploads/Consolidated-Wage-Forms-ABC.csv</E>
                     and 
                    <E T="03">https://www.stb.gov/wp-content/uploads/Instructions-for-Consolidated-Wage-Forms-A-B-C.pdf,</E>
                     respectively. It should be noted that the form for these reports have been reformatted in a way that should allow for more efficient submission and agency processing, but the information has not changed. They continue to contain all of the same data elements. The information contained in these reports is not available from any other source.
                </P>
                <HD SOURCE="HD1">Description of Collection 3</HD>
                <P>
                    <E T="03">Title:</E>
                     Monthly Report of Number of Employees of Class I Railroads (Wage Form C).
                </P>
                <P>
                    <E T="03">OMB Control Number:</E>
                     2140-0007.
                </P>
                <P>
                    <E T="03">Form Number:</E>
                     STB Form C.
                </P>
                <P>
                    <E T="03">Type of Review:</E>
                     Extension without change.
                </P>
                <P>
                    <E T="03">Respondents:</E>
                     Class I railroads.
                </P>
                <P>
                    <E T="03">Number of Respondents:</E>
                     Seven.
                </P>
                <P>
                    <E T="03">Estimated Time per Response:</E>
                     1.25 hours.
                </P>
                <P>
                    <E T="03">Frequency of Response:</E>
                     Monthly.
                </P>
                <P>
                    <E T="03">Total Annual Hour Burden:</E>
                     105 hours annually.
                </P>
                <P>
                    <E T="03">Total Annual “Non-Hour Burden” Cost:</E>
                     None identified. Filings are submitted electronically to the Board.
                </P>
                <P>
                    <E T="03">Needs and Uses:</E>
                     This collection shows, for each reporting carrier, the average number of employees at mid-month in the six job-classification groups that encompass all railroad employees. 
                    <E T="03">See</E>
                     49 CFR part 1246. The information is used by the Board to forecast labor costs and measure the efficiency of the reporting railroads. The information is also used by the Board to evaluate the impact on rail employees of proposed regulated transactions, including mergers and consolidations, acquisitions of control, purchases, and abandonments. Other Federal agencies and industry groups, including the RRB, BLS, and AAR, use the information contained in these reports to monitor 
                    <PRTPAGE P="63461"/>
                    railroad operations. Certain information from these reports is compiled and published on the Board's website, 
                    <E T="03">https://www.stb.gov/stb/industry/econ_reports.html.</E>
                     The reformatted form and instructions may be viewed at 
                    <E T="03">https://www.stb.gov/wp-content/uploads/Consolidated-Wage-Forms-ABC.csv</E>
                     and 
                    <E T="03">https://www.stb.gov/wp-content/uploads/Instructions-for-Consolidated-Wage-Forms-A-B-C.pdf,</E>
                     respectively. It should be noted that the form for this report has been reformatted in a way that should allow for more efficient submission and agency processing, but the information has not changed. The form continues to contain all of the same data elements. The information contained in this report is not available from any other source.
                </P>
                <HD SOURCE="HD1">Description of Collection 4</HD>
                <P>
                    <E T="03">Title:</E>
                     Annual Report of Cars Loaded and Cars Terminated.
                </P>
                <P>
                    <E T="03">OMB Control Number:</E>
                     2140-0011.
                </P>
                <P>
                    <E T="03">Form Number:</E>
                     Form STB-54.
                </P>
                <P>
                    <E T="03">Type of Review:</E>
                     Extension without change.
                </P>
                <P>
                    <E T="03">Respondents:</E>
                     Class I railroads.
                </P>
                <P>
                    <E T="03">Number of Respondents:</E>
                     Seven.
                </P>
                <P>
                    <E T="03">Estimated Time per Response:</E>
                     Four hours.
                </P>
                <P>
                    <E T="03">Frequency of Response:</E>
                     Annual.
                </P>
                <P>
                    <E T="03">Total Annual Hour Burden:</E>
                     28 hours annually.
                </P>
                <P>
                    <E T="03">Total Annual “Non-Hour Burden” Cost:</E>
                     None identified. Filings are submitted electronically to the Board.
                </P>
                <P>
                    <E T="03">Needs and Uses:</E>
                     This collection reports the number of cars loaded and cars terminated on the reporting carrier's line. 
                    <E T="03">See</E>
                     49 CFR part 1247. Information in this report is entered into the Board's Uniform Rail Costing System (URCS), which is a cost measurement methodology. URCS, which was developed by the Board pursuant to 49 U.S.C. 11161, is used as a tool in rail rate proceedings, in accordance with 49 U.S.C. 10707(d), to calculate the variable costs associated with providing a particular service. The Board also uses URCS to carry out more effectively other of its regulatory responsibilities, including: acting on railroad requests for authority to engage in Board-regulated financial transactions such as mergers, acquisitions of control, and consolidations, 
                    <E T="03">see</E>
                     49 U.S.C. 11323-11324; analyzing the information that the Board obtains through the annual railroad industry waybill sample, 
                    <E T="03">see</E>
                     49 CFR 1244; measuring off-branch costs in railroad abandonment proceedings, in accordance with 49 CFR 1152.32(n); developing the “rail cost adjustment factors,” in accordance with 49 U.S.C. 10708; and conducting investigations and rulemakings. This collection is compiled and published on the Board's website, 
                    <E T="03">https://www.stb.gov/stb/industry/econ_reports.html.</E>
                     The reformatted form and instructions may be viewed at 
                    <E T="03">https://www.stb.gov/wp-content/uploads/STB-54-Cars-Loaded-and-Terminated.csv</E>
                     and 
                    <E T="03">https://www.stb.gov/wp-content/uploads/Instructions-for-STB-54-Cars-Loaded-and-Terminated.pdf,</E>
                     respectively. It should be noted that the form for this report has been reformatted in a way that should allow for more efficient submission and agency processing, but the information has not changed. The form continues to contain all of the same data elements. The information contained in this report is not available from any other source.
                </P>
                <HD SOURCE="HD1">Description of Collection 5</HD>
                <P>
                    <E T="03">Title:</E>
                     Quarterly Report of Revenues, Expenses, and Income—Railroads (Form RE&amp;I).
                </P>
                <P>
                    <E T="03">OMB Control Number:</E>
                     2140-0013.
                </P>
                <P>
                    <E T="03">Form Number:</E>
                     Form RE&amp;I.
                </P>
                <P>
                    <E T="03">Type of Review:</E>
                     Extension without change.
                </P>
                <P>
                    <E T="03">Respondents:</E>
                     Class I railroads.
                </P>
                <P>
                    <E T="03">Number of Respondents:</E>
                     Seven.
                </P>
                <P>
                    <E T="03">Estimated Time per Response:</E>
                     Six hours.
                </P>
                <P>
                    <E T="03">Frequency of Response:</E>
                     Quarterly.
                </P>
                <P>
                    <E T="03">Total Annual Hour Burden:</E>
                     168 hours annually.
                </P>
                <P>
                    <E T="03">Total Annual “Non-Hour Burden” Cost:</E>
                     None identified. Filings are submitted electronically to the Board.
                </P>
                <P>
                    <E T="03">Needs and Uses:</E>
                     This collection is a report of railroad operating revenues, operating expenses, and income items. It is also a profit and loss statement, disclosing net railway operating income on a quarterly and year-to-date basis for current and prior years. 
                    <E T="03">See</E>
                     49 CFR 1243.1. The Board uses the information in this report to ensure competitive, efficient, and safe transportation through general oversight programs that monitor and forecast the financial and operating condition of railroads, and through regulation of railroad rate and service issues and rail restructuring proposals, including railroad mergers, consolidations, acquisitions of control, and abandonments. Information from these reports is used by the Board, other Federal agencies, and industry groups to monitor and assess industry growth and operations, detect changes in carrier financial stability, and identify trends that may affect the national transportation system. Some of the information from these reports is compiled by the Board in our quarterly Selected Earnings Data Report, which is published on the Board's website, 
                    <E T="03">https://www.stb.gov/stb/industry/econ_reports.html.</E>
                     The reformatted form and instructions may be viewed at 
                    <E T="03">https://www.stb.gov/wp-content/uploads/Revenue-Expenses-and-Income.csv</E>
                     and 
                    <E T="03">https://www.stb.gov/wp-content/uploads/Instructions-for-Revenue-Expenses-and-Income.pdf,</E>
                     respectively. It should be noted that the form for this report has been reformatted in a way that should allow for more efficient submission and agency processing, but the information has not changed. The form continues to contain all of the same data elements. The information contained in this report is not available from any other source.
                </P>
                <HD SOURCE="HD1">Description of Collection 6</HD>
                <P>
                    <E T="03">Title:</E>
                     Quarterly Condensed Balance Sheet—Railroads (Form CBS).
                </P>
                <P>
                    <E T="03">OMB Control Number:</E>
                     2140-0014.
                </P>
                <P>
                    <E T="03">Form Number:</E>
                     Form CBS.
                </P>
                <P>
                    <E T="03">Type of Review:</E>
                     Extension without change.
                </P>
                <P>
                    <E T="03">Respondents:</E>
                     Class I railroads.
                </P>
                <P>
                    <E T="03">Number of Respondents:</E>
                     Seven.
                </P>
                <P>
                    <E T="03">Estimated Time per Response:</E>
                     Six hours.
                </P>
                <P>
                    <E T="03">Frequency of Response:</E>
                     Quarterly.
                </P>
                <P>
                    <E T="03">Total Annual Hour Burden:</E>
                     168 hours annually.
                </P>
                <P>
                    <E T="03">Total Annual “Non-Hour Burden” Cost:</E>
                     None identified. Filings are submitted electronically to the Board.
                </P>
                <P>
                    <E T="03">Needs and Uses:</E>
                     This collection shows the balance, quarterly and cumulative, for the current and prior year of the carrier's assets and liabilities, gross capital expenditures, and revenue tons carried. 
                    <E T="03">See</E>
                     49 CFR 1243.2. The Board uses the information in this report to ensure competitive, efficient, and safe transportation through general oversight programs that monitor and forecast the financial and operating condition of railroads, and through specific regulation of railroad rate and service issues and rail restructuring proposals, including railroad mergers, consolidations, acquisitions of control, and abandonments. Information from these reports is used by the Board, other Federal agencies, and industry groups to assess industry growth and operations, detect changes in carrier financial stability, and identify trends that may affect the national transportation system. Revenue ton-miles, which are reported in these reports, are compiled and published by the Board in its quarterly Selected Earnings Data Report, which is published on the Board's website, 
                    <E T="03">https://www.stb.gov/stb/industry/econ_reports.html.</E>
                     The reformatted form and instructions may be viewed at 
                    <E T="03">https://www.stb.gov/wp-content/uploads/Condensed-Balance-Sheet.csv</E>
                     and 
                    <E T="03">
                        https://www.stb.gov/wp-content/uploads/Instructions-for-
                        <PRTPAGE P="63462"/>
                        Condensed-Balance-Sheet.pdf,
                    </E>
                     respectively. It should be noted that the form for this report has been reformatted in a way that should allow for more efficient submission and agency processing, but the information has not changed. The form continues to contain all of the same data elements. The information contained in this report is not available from any other source.
                </P>
                <P>
                    The Board makes this submission because, under the PRA, a Federal agency that conducts or sponsors a collection of information must display a currently valid OMB control number. A collection of information, which is defined in 44 U.S.C. 3502(3) and 5 CFR 1320.3(c), includes agency requirements that persons submit reports, keep records, or provide information to the agency, third parties, or the public. Under 44 U.S.C. 3506(c)(2)(A), Federal agencies are required to provide, prior to an agency's submitting a collection to OMB for approval, a 60-day notice and comment period through publication in the 
                    <E T="04">Federal Register</E>
                     concerning each proposed collection of information, including each proposed extension of an existing collection of information.
                </P>
                <SIG>
                    <DATED>Dated: July 31, 2024.</DATED>
                    <NAME>Kenyatta Clay,</NAME>
                    <TITLE>Clearance Clerk.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17184 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4915-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">OFFICE OF THE UNITED STATES TRADE REPRESENTATIVE</AGENCY>
                <DEPDOC>[Docket Number USTR-2024-0012]</DEPDOC>
                <SUBJECT>Request for Comments and Notice of Public Hearing Concerning China's Compliance With WTO Commitments</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Office of the United States Trade Representative.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Request for comments and notice of public hearing.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The interagency Trade Policy Staff Committee (TPSC) is seeking public comments to assist the Office of the United States Trade Representative (USTR) in the preparation of its annual report to Congress on China's compliance with its obligations as a Member of the World Trade Organization (WTO). This notice includes the schedule for the submission of comments to the TPSC for the China report and a public hearing.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P/>
                    <P>
                        <E T="03">September 10, 2024 at 11:59 p.m. EDT:</E>
                         Deadline for submission of written comments, requests to testify, and summaries of written testimony.
                    </P>
                    <P>
                        <E T="03">September 24, 2024 at 9:30 a.m. EDT:</E>
                         The TPSC will convene a public hearing to receive oral testimony.
                    </P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        USTR strongly prefers electronic submissions made through the Federal eRulemaking Portal: 
                        <E T="03">https://www.regulations.gov</E>
                         (
                        <E T="03">Regulations.gov</E>
                        ). Follow the instructions for submitting written comments and testimony and requests to testify in sections III and IV below, using Docket Number USTR-2024-0012. For alternatives to on-line submissions, please contact Alex Martin, Deputy Director for China Affairs, in advance of the relevant deadline at 
                        <E T="03">Thomas.A.Martin@ustr.eop.gov</E>
                         or 202.395.9625.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Alex Martin, Deputy Director for China Affairs at 
                        <E T="03">Thomas.A.Martin@ustr.eop.gov</E>
                         or (202) 395-9625.
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">I. Background</HD>
                <P>
                    China became a Member of the WTO on December 11, 2001. In accordance with section 421 of the U.S.-China Relations Act of 2000 (Pub. L. 106-286), USTR is required to submit, on or about December 11 of each year, a report to Congress on China's compliance with commitments made in connection with its accession to the WTO, including both multilateral commitments and any bilateral commitments made to the United States. In accordance with section 421, and to assist it in preparing this year's report, the TPSC is soliciting public comments. You can find last year's report on the USTR website at: 
                    <E T="03">https://ustr.gov/sites/default/files/USTR%20Report%20on%20China's%20WTO%20Compliance%20(Final).pdf.</E>
                </P>
                <P>
                    The terms of China's accession to the WTO are contained in the Protocol on the Accession of the People's Republic of China (including its annexes) (Protocol), the Report of the Working Party on the Accession of China (Working Party Report), and the WTO agreements. You can find the Protocol and Working Party Report on the WTO website at 
                    <E T="03">http://docsonline.wto.org</E>
                     (document symbols: WT/L/432, WT/MIN(01)/3, WT/MIN(01)/3/Add.1, WT/MIN(01)/3/Add.2).
                </P>
                <HD SOURCE="HD1">II. Hearing Participation</HD>
                <P>
                    USTR will convene a public hearing on September 24, 2024, related to China's compliance with its WTO commitments. Persons wishing to observe the public hearing will find a link on USTR's web page for China on the day of the hearing at 
                    <E T="03">https://ustr.gov/countries-regions/china-mongolia-taiwan.</E>
                     To ensure participation, you must submit requests to present oral testimony at the hearing and written testimony by midnight on September 10, 2024, via 
                    <E T="03">Regulations.gov,</E>
                     using Docket Number USTR-2024-0012. Instructions for submission are in Sections III and IV below. Remarks at the hearing will be limited to no more than five minutes to allow for possible questions from the TPSC. Because it is a public hearing, testimony should not include any business confidential information (BCI). USTR will provide a link in advance of the virtual hearing to persons wishing to testify.
                </P>
                <P>The TPSC requests small businesses or organizations representing small business members that submit comments to self-identify as such, so that we may be aware of issues of particular interest to small businesses.</P>
                <P>Written comments and/or oral testimony should address China's compliance with the commitments made in connection with its accession to the WTO, including, but not limited to, commitments in the following areas:</P>
                <P>A. Trading rights.</P>
                <P>
                    B. Import regulation (
                    <E T="03">e.g.,</E>
                     tariffs, tariff-rate quotas, quotas, import licenses).
                </P>
                <P>C. Export regulation.</P>
                <P>
                    D. Internal policies affecting trade (
                    <E T="03">e.g.,</E>
                     subsidies, standards and technical regulations, sanitary and phytosanitary measures, government procurement, trade-related investment measures, taxes and charges levied on imports and exports).
                </P>
                <P>E. Intellectual property rights (including intellectual property rights enforcement).</P>
                <P>F. Services.</P>
                <P>
                    G. Rule of law issues (
                    <E T="03">e.g.,</E>
                     transparency, judicial review, uniform administration of laws and regulations) and status of legal reform.
                </P>
                <P>H. Other WTO commitments.</P>
                <P>In addition, given the United States' view that China should be held accountable as a full participant in, and beneficiary of, the international trading system, USTR requests that interested persons specifically identify unresolved compliance issues that warrant review and evaluation by USTR.</P>
                <HD SOURCE="HD1">III. Procedures for Written Submissions</HD>
                <P>
                    To be assured of consideration, submit your written comments, requests to testify, and summaries of written testimony by the September 10, 2024 11:59 p.m. EDT deadline. All submissions must be in English. The TPSC strongly encourages submissions via 
                    <E T="03">Regulations.gov,</E>
                     using Docket Number USTR-2024-0012.
                    <PRTPAGE P="63463"/>
                </P>
                <P>
                    To make a submission via 
                    <E T="03">Regulations.gov,</E>
                     enter Docket Number USTR-2024-0012 in the `search for' field on the home page and click `search.' The site will provide a search results page listing all documents associated with this docket. Find a reference to this notice by selecting `notice' under `document type' in the `refine documents results' section on the left side of the screen and click on the link entitled `comment.'
                </P>
                <P>
                    <E T="03">Regulations.gov</E>
                     allows users to make submissions by filling in a `type comment' field, or by attaching a document using the `upload file' field. USTR prefers that you provide submissions in an attached document and, in such cases, that you write `see attached' in the `type comment' field. USTR prefers submissions in Microsoft Word (.doc) or Adobe Acrobat (.pdf). If you use an application other than those two, please indicate the name of the application in the `type comment' field.
                </P>
                <P>
                    At the beginning of your submission or on the first page (if an attachment), include the following text: (1) 2024 China WTO Compliance Report; (2) your organization's name; and (3) whether the submission is a written comment, request to testify, or summary of written testimony. Submissions should not exceed 30 single-spaced, standard letter-size pages in 12-point type, including attachments. Please do not attach separate cover letters, exhibits, annexes, or other attachments to electronic submissions; rather, include any in the same file as the submission itself, not as separate files. You will receive a tracking number upon completion of the submission procedure at 
                    <E T="03">Regulations.gov.</E>
                     The tracking number is confirmation that 
                    <E T="03">Regulations.gov</E>
                     received your submission. Keep the confirmation for your records. USTR is not able to provide technical assistance for 
                    <E T="03">Regulations.gov.</E>
                </P>
                <P>
                    For further information on using 
                    <E T="03">Regulations.gov,</E>
                     please consult the resources provided on the website by clicking on `How to Use 
                    <E T="03">Regulations.gov</E>
                    ' on the bottom of the home page. USTR may not consider submissions that you do not make in accordance with these instructions.
                </P>
                <P>
                    If you are unable to provide submissions as requested, please contact Alex Martin, Deputy Director for China Affairs, in advance of the deadline at 
                    <E T="03">Thomas.A.Martin@ustr.eop.gov</E>
                     or (202) 395-9625, to arrange for an alternative method of transmission. USTR will not accept hand-delivered submissions.
                </P>
                <P>
                    General information concerning USTR is available at 
                    <E T="03">www.ustr.gov.</E>
                </P>
                <HD SOURCE="HD1">IV. Business Confidential Information (BCI) Submissions</HD>
                <P>If you ask USTR to treat information you submit as BCI, you must certify that the information is business confidential and you would not customarily release it to the public. For any comments submitted electronically containing BCI, the file name of the business confidential version should begin with the characters `BCI.' You must clearly mark any page containing BCI with `BUSINESS CONFIDENTIAL' at the top of that page. Filers of submissions containing BCI also must submit a public version of their submission that will be placed in the docket for public inspection. The file name of the public version should begin with the character `P.'</P>
                <HD SOURCE="HD1">V. Public Viewing of Review Submissions</HD>
                <P>
                    USTR will post written submissions in the docket for public inspection, except properly designated BCI. You can view submissions at 
                    <E T="03">Regulations.gov</E>
                     by entering Docket Number USTR-2024-0012 in the search field on the home page.
                </P>
                <SIG>
                    <NAME>Laura Buffo,</NAME>
                    <TITLE>Chair of the Trade Policy Staff Committee, Office of the United States Trade Representative.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17235 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 3390-F4-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">OFFICE OF THE UNITED STATES TRADE REPRESENTATIVE</AGENCY>
                <DEPDOC>[Docket Number USTR-2024-0011]</DEPDOC>
                <SUBJECT>Request for Comments and Notice of Public Hearing Concerning Russia's Implementation of Its WTO Commitments</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Office of the United States Trade Representative.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Request for comments and notice of public hearing.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The interagency Trade Policy Staff Committee (TPSC) is seeking public comments to assist the Office of the United States Trade Representative (USTR) in the preparation of its annual report to Congress on Russia's implementation of its obligations as a Member of the World Trade Organization (WTO). This notice includes the schedule for the submission of comments to the TPSC for the Russia report and a public hearing.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P/>
                    <P>
                        <E T="03">September 18, 2024 at 11:59 p.m. EDT:</E>
                         Deadline for submission of written comments, requests to testify, and written testimony, regarding the Russia WTO implementation report.
                    </P>
                    <P>
                        <E T="03">October 10, 2024 at 10:00 a.m. EDT:</E>
                         The TPSC will convene a public hearing to receive oral testimony related to the Russia WTO implementation report.
                    </P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        USTR strongly prefers electronic submissions made through the Federal eRulemaking Portal: 
                        <E T="03">http://www.regulations.gov</E>
                         (
                        <E T="03">Regulations.gov</E>
                        ). Follow the instructions for submitting comments in sections III and IV below, using docket number USTR-2024-0011. For alternatives to on-line submissions, please contact Silvia Savich, Deputy Assistant U.S. Trade Representative for Russia and Eurasia, in advance of the relevant deadline at 
                        <E T="03">Silvia.Savich@ustr.eop.gov</E>
                         or 202.395.2256.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Silvia Savich, Deputy Assistant U.S. Trade Representative for Russia and Eurasia, at 
                        <E T="03">Silvia.Savich@ustr.eop.gov</E>
                         or 202.395.2256.
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">I. Background</HD>
                <P>
                    Russia became a Member of the WTO on August 22, 2012, and on December 21, 2012, following termination of the application of the Jackson-Vanik amendment to Russia and the extension of permanent normal trade relations to the products of Russia, the United States and Russia filed letters with the WTO withdrawing their notices of non-application and consenting to have the WTO Agreement apply between them. In accordance with Section 201(a) of the Russia and Moldova Jackson-Vanik Repeal and Sergei Magnitsky Rule of Law Accountability Act of 2012 (Pub. L. 112-208), USTR is required to submit annually a report to Congress on the extent to which Russia is implementing the WTO Agreement, including the Agreement on the Application of Sanitary and Phytosanitary Measures and the Agreement on Trade Related Aspects of Intellectual Property Rights. The report also must assess Russia's progress on acceding to and implementing the Information Technology Agreement (ITA) and the Government Procurement Agreement (GPA). In addition, to the extent that USTR finds that Russia is not implementing fully any WTO agreement or is not making adequate progress in acceding to the ITA or the GPA, USTR must describe in the report the actions it plans to take to encourage Russia to improve its implementation and/or increase its accession efforts. In accordance with Section 201(a), and to assist it in preparing this year's report, the TPSC is soliciting public comments. You can find last year's report on 
                    <PRTPAGE P="63464"/>
                    USTR's website at: 
                    <E T="03">https://ustr.gov/sites/default/files/2023%20Report%20on%20the%20Implementation%20and%20Enforcement%20of%20Russia's%20WTO%20Commitments.pdf.</E>
                </P>
                <P>
                    The terms of Russia's accession to the WTO are contained in the Marrakesh Agreement Establishing the World Trade Organization and the Protocol on the Accession of the Russian Federation to the WTO (including its annexes) (Protocol). The Report of the Working Party on the Accession of the Russian Federation (Working Party Report) provides detail and context to the commitments listed in the Protocol. You can find the Protocol and Working Party Report on USTR's website at 
                    <E T="03">https://ustr.gov/node/5887</E>
                     or on the WTO website at 
                    <E T="03">http://docsonline.wto.org</E>
                     (document symbols: WT/ACC/RUS/70, WT/MIN(11)/2, WT/MIN(11)/24, WT/L/839, WT/ACC/RUS/70/Add.1, WT/MIN(11)/2/Add.1, WT/ACC/RUS/70/Add.2, and WT/MIN(11)/2/Add.1.)
                </P>
                <HD SOURCE="HD1">II. Hearing Participation</HD>
                <P>
                    USTR will convene a public hearing on October 10, 2024 related to Russia's implementation of its WTO commitments. Persons wishing to observe the public hearing will find a link on USTR's web page for Russia on the day of the hearing at 
                    <E T="03">https://ustr.gov/countries-regions/europe-middle-east/russia-and-eurasia/russia.</E>
                     To ensure participation, you must submit requests to present oral testimony at the hearing and written testimony by midnight on September 19, 2024, via 
                    <E T="03">Regulations.gov,</E>
                     using Docket Number USTR-2024-0011. Instructions for submission are in Sections III and IV below. Remarks at the hearing will be limited to no more than five minutes to allow for possible questions from the TPSC. Because it is a public the hearing, testimony should not include any business confidential information (BCI). USTR will provide a link in advance of the virtual hearing to persons wishing to testify.
                </P>
                <P>The TPSC requests small businesses or organizations representing small business members that submit comments to self-identify as such, so that we may be aware of issues of particular interest to small businesses.</P>
                <P>Written comments and/or oral testimony should address Russia's implementation of the commitments made in connection with its accession to the WTO, including, but not limited to, commitments in the following areas:</P>
                <P>
                    a. Import regulation (
                    <E T="03">e.g.,</E>
                     tariffs, tariff-rate quotas, quotas, import licenses).
                </P>
                <P>b. Export regulation.</P>
                <P>c. Subsidies.</P>
                <P>d. Standards and technical regulations.</P>
                <P>e. Sanitary and phytosanitary measures.</P>
                <P>f. Trade-related investment measures (including local content requirements).</P>
                <P>g. Taxes and charges levied on imports and exports.</P>
                <P>h. Other internal policies affecting trade.</P>
                <P>i. Intellectual property rights (including intellectual property rights enforcement).</P>
                <P>j. Services.</P>
                <P>k. Government procurement.</P>
                <P>
                    l. Rule of law issues (
                    <E T="03">e.g.,</E>
                     transparency, judicial review, uniform administration of laws and regulations).
                </P>
                <P>m. Trade facilitation.</P>
                <P>n. Other WTO commitments.</P>
                <HD SOURCE="HD1">III. Procedures for Written Submissions</HD>
                <P>
                    To be assured of consideration, submit your written comments, requests to testify, and written testimony by the September 18, 2024, 11:59 p.m. EDT deadline. All submissions must be in English. USTR strongly encourages submissions via 
                    <E T="03">Regulations.gov,</E>
                     using Docket Number USTR-2024-0011.
                </P>
                <P>
                    To make a submission via 
                    <E T="03">Regulations.gov,</E>
                     enter Docket Number USTR-2024-0011 in the `search for' field on the home page and click `search.' The site will provide a search results page listing all documents associated with this docket. Find a reference to this notice by selecting `notice' under `document type' in the `refine documents results' section on the left side of the screen and click on the link entitled `comment.' 
                    <E T="03">Regulations.gov</E>
                     allows users to make submissions by filling in a `type comment' field, or by attaching a document using the `upload file' field. USTR prefers that you provide submissions in an attached document and, in such cases, that you write `see attached' in the `type comment' field. USTR prefers submissions in Microsoft Word (.doc) or Adobe Acrobat (.pdf). If you use an application other than those two, please indicate the name of the application in the `type comment' field.
                </P>
                <P>
                    At the beginning of your submission or on the first page (if an attachment), include the following text: (1) 2024 Russia WTO Implementation Report; (2) your organization's name; and (3) whether the submission is a comment, request to testify, or written testimony. Submissions should not exceed 30 single-spaced, standard letter-size pages in 12-point type, including attachments. Please do not attach separate cover letters, exhibits, annexes, or other attachments to electronic submissions; rather, include any in the same file as the submission itself, not as separate files. You will receive a tracking number upon completion of the submission procedure at 
                    <E T="03">Regulations.gov.</E>
                     The tracking number is confirmation that 
                    <E T="03">Regulations.gov</E>
                     received your submission. Keep the confirmation for your records.
                </P>
                <P>
                    USTR is not able to provide technical assistance for 
                    <E T="03">Regulations.gov.</E>
                     For further information on using 
                    <E T="03">Regulations.gov,</E>
                     please consult the resources provided on the website by clicking on `How to Use 
                    <E T="03">Regulations.gov</E>
                    ' on the bottom of the home page. USTR may not consider submissions that you do not make in accordance with these instructions.
                </P>
                <P>
                    If you are unable to provide submissions through 
                    <E T="03">Regulations.gov</E>
                     after seeking assistance from the help desk, please contact Silvia Savich, Deputy Assistant U.S. Trade Representative for Russia and Eurasia, in advance of the deadline at 
                    <E T="03">Silvia.Savich@ustr.eop.gov</E>
                     or 202.395.2256, to arrange for an alternative method of transmission. USTR will not accept hand-delivered submissions. USTR may not consider submissions that you do not make in accordance with these instructions.
                </P>
                <P>
                    General information concerning USTR is available at 
                    <E T="03">www.ustr.gov.</E>
                </P>
                <HD SOURCE="HD1">IV. Business Confidential Information (BCI) Submissions</HD>
                <P>If you ask USTR to treat information you submit as BCI, you must certify that the information is business confidential and you would not customarily release it to the public. For any comments submitted electronically containing BCI, the file name of the business confidential version should begin with the characters `BCI.' You must clearly mark any page containing BCI with `BUSINESS CONFIDENTIAL' at the top of that page. Filers of submissions containing BCI also must submit a public version of their submission that will be placed in the docket for public inspection. The file name of the public version should begin with the character `P.' Follow the `BCI' and `P' with the name of the individual or organization submitting the comments.</P>
                <HD SOURCE="HD1">V. Public Viewing of Review Submissions</HD>
                <P>
                    USTR will post written submissions in the docket for public inspection, except properly designated BCI. You can view submissions at 
                    <E T="03">Regulations.gov</E>
                     by entering Docket 
                    <PRTPAGE P="63465"/>
                    Number USTR-2024-0011 in the search field on the home page.
                </P>
                <SIG>
                    <NAME>Laura Buffo,</NAME>
                    <TITLE>Chair of the Trade Policy Staff Committee, Office of the United States Trade Representative.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17229 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 3390-F4-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">OFFICE OF THE UNITED STATES TRADE REPRESENTATIVE</AGENCY>
                <DEPDOC>[Docket Number USTR-2024-0010]</DEPDOC>
                <SUBJECT>Request for Comments and Public Hearing About the Administration's Action Following a Determination of Import Injury With Regard to Fine Denier Polyester Staple Fiber (PSF)</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Office of the United States Trade Representative.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Request for comments and notice of public hearing.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>On July 9, 2024, the United States International Trade Commission (USITC) determined that fine denier polyester staple fiber (PSF) is being imported into the United States in such increased quantities as to be a substantial cause of serious injury, or the threat thereof, to the domestic industry producing an article that is like or directly competitive with the imported article. The Commissioners who voted in the affirmative are now conducting a process to recommend a safeguard measure for the President. The Office of the United States Trade Representative (USTR), on behalf of the Trade Policy Staff Committee (TPSC), is announcing a process so that, once the USITC makes its recommendation and issues its report to the President, domestic producers, importers, exporters, and other interested parties subsequently may submit their views and evidence on the appropriateness of the recommended safeguard measure and whether it would be in the public interest. USTR also invites interested parties to participate in a public hearing regarding this matter.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P/>
                    <P>
                        <E T="03">September 9, 2024 at 11:59 p.m. EST:</E>
                         Deadline for submission of written comments, requests to testify, and summaries of written testimony.
                    </P>
                    <P>
                        <E T="03">September 16, 2024 at 11:59 p.m. EST:</E>
                         Deadline for submission of written responses to the initial round of comments.
                    </P>
                    <P>
                        <E T="03">September 30, 2024:</E>
                         The TPSC will hold a public hearing in Rooms 1 and 2, 1724 F Street NW, Washington, DC.
                    </P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        USTR strongly prefers electronic submissions made through the Federal eRulemaking Portal: 
                        <E T="03">http://www.regulations.gov</E>
                         (
                        <E T="03">Regulations.gov</E>
                        ). Follow the instructions for submitting comments in section III below. The docket number is USTR-2024-0010. For alternatives to on-line submissions, please contact Rachel Hasandras at 
                        <E T="03">Rachel.B.Hasandras@ustr.eop.gov.</E>
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Victor Mroczka, Office of WTO and Multilateral Affairs, at 
                        <E T="03">Victor_S_Mroczka@ustr.eop.gov</E>
                         or 202.395.9450; Rachel Hasandras or Michael Gagain, Office of the General Counsel, at or 202.395.9529, or respectively, 
                        <E T="03">Rachel.B.Hasandras@ustr.eop.gov</E>
                         or 
                        <E T="03">Michael.T.Gagain@ustr.eop.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">I. The USITC Investigation and Section 201</HD>
                <P>On March 8, 2024, following receipt of a petition for import relief, as filed on February 28, 2024, the USITC instituted investigation No. TA-201-078 under section 202 of the Trade Act of 1974 (19 U.S.C. 2252) on imported PSF, on the basis of a petition requesting import relief properly filed by Fiber Industries LLC d/b/a Darling Fibers, Nan Ya Plastics Corp. America, and Sun Fiber (collectively, petitioners). The USITC notice of institution (89 FR 18435) identifies the scope of the products covered by this investigation.</P>
                <P>
                    On July 9, 2024, after receiving submissions from interested parties and holding a public hearing on June 4, 2024 that provided an opportunity to present opposing views and supporting evidence, the USITC determined that the increased importation of PSF is a substantial cause of serious injury, or threat thereof, to the domestic industry. The USITC determination and additional information about the investigation, including the administrative record consisting of briefs and other submissions, can be found in the Electronic Document Information System (EDIS) on the USITC website at 
                    <E T="03">www.usitc.gov.</E>
                </P>
                <P>By August 26, 2024, after the remedy hearing and consideration of the submissions, the USITC will submit to the President a report with its recommendation on action(s) to address the serious injury, or threat thereof, to the domestic industry and to facilitate the efforts of the domestic industry to make a positive adjustment to import competition.</P>
                <HD SOURCE="HD1">II. Proposed Measure and Opportunity To Comment</HD>
                <P>Section 201 of the Trade Act of 1974 (19 U.S.C. 2251) authorizes the President, in the event of an affirmative determination by the USITC, to take all appropriate and feasible action within his power that he determines will facilitate efforts by the domestic industry to make a positive adjustment to import competition and provide greater economic and social benefits than costs. The statute provides for the President to take action within 60 days after receiving the USITC report, subject to any decision the President makes to request additional information from the USITC. As noted above, the USITC is scheduled to transmit its report to the President by August 26, 2024. In accordance with section 203(a)(1)(C) of the Trade Act of 1974 (19 U.S.C. 2253(a)(1)(C)), the TPSC will make a recommendation to the President. This recommendation will take into account the USITC recommendation, the extent to which the domestic industry will benefit from adjustment assistance, the efforts of the domestic industry to make positive adjustments, and other relevant considerations. The potential actions the President may take to provide a remedy in the form of a safeguard measure include:</P>
                <P>• Imposition, or increase, of a duty on the imported articles in question.</P>
                <P>• Use of a tariff-rate quota.</P>
                <P>• Modification or imposition of any quantitative restriction on the importation of the articles into the United States.</P>
                <P>• A proposal to negotiate and carry out an agreement with foreign countries to limit the exportation from foreign countries and importation into the United States.</P>
                <P>• Procedures for the granting of import licenses.</P>
                <P>• Other negotiations to identify the underlying cause of the increased imports to alleviate the injury or threat thereof.</P>
                <P>• Legislative proposals that would facilitate a positive adjustment.</P>
                <P>• Other action consistent with the President's authority.</P>
                <P>• Any combination of these actions.</P>
                <P>USTR offers these potential remedies for further consideration by domestic producers, importers, exporters, and other interested parties, and invites views and evidence on whether a proposed remedy is appropriate and in the public interest. In commenting on the action to take, we request that you address:</P>
                <P>1. The appropriateness of any other proposed action and how it would be in the public interest.</P>
                <P>
                    2. The short- and long-term effects the proposed action is likely to have on the domestic PSF industry, other domestic industries, and downstream consumers.
                    <PRTPAGE P="63466"/>
                </P>
                <P>3. The short- and long-term effects that not taking the proposed action is likely to have on the domestic PSF industry, its workers, and on other domestic industries and communities.</P>
                <HD SOURCE="HD1">III. Hearing Participation</HD>
                <P>The TPSC will convene a public hearing on September 30, 2024, in Rooms 1 and 2, 1724 F Street NW, Washington, DC. USTR will provide information about the format and schedule for the hearing to interested parties. Requests to testify must include the following information: (1) name, address, telephone number, email address, and firm or affiliation of the individual wishing to testify, and (2) a brief summary of the proposed oral presentation.</P>
                <HD SOURCE="HD1">IV. Submission Instructions</HD>
                <P>USTR seeks public comments with respect to the issues described in Section II. To be assured of consideration, you must submit written comments, requests to appear at the hearing, and summaries of testimony by 11:59 p.m. EST on September 09, 2024, and any written responses to those comments by 11:59 p.m. EST on September 16, 2024. The request to appear must include a summary of testimony, and may be accompanied by a prehearing submission. All comments must be in English and must identify on the reference line of the first page of the submission “Potential Action: Fine Denier PSF.” </P>
                <P>
                    USTR strongly encourages commenters to make on-line submissions, using 
                    <E T="03">Regulations.gov</E>
                    . To submit comments via 
                    <E T="03">Regulations.gov</E>
                    , enter docket number USTR-2024-0010 on the home page and click “search.” The site will provide a search-results page listing all documents associated with this docket. Find a reference to this notice and click on the link entitled “Comment Now!”
                </P>
                <P>
                    For further information on using 
                    <E T="03">Regulations.gov</E>
                    , please consult the resources provided on the website by clicking “How to Use Regulations.gov” on the bottom of the home page. USTR will not accept hand-delivered submissions.
                </P>
                <P>
                    The 
                    <E T="03">Regulations.gov</E>
                     website allows users to provide comments by filling in a “Type Comment” field, or by attaching a document using an “Upload File” field. USTR prefers that you provide comments as an attached document in Microsoft Word (.doc) or Adobe Acrobat (.pdf) format. If the submission is in another file format, please indicate the name of the software application in the “Type Comment” field. File names should reflect the name of the person or entity submitting the comments. Please do not attach separate cover letters to electronic submissions; rather, include any information that might appear in a cover letter in the comments themselves. Similarly, to the extent possible, please include any exhibits, annexes, or other attachments in the same file as the comment itself, rather than submitting them as separate files.
                </P>
                <P>For any comments submitted electronically that contain business confidential information (BCI), the file name of the business confidential version should begin with the characters “BCI”. Any page containing business confidential information must be clearly marked “BUSINESS CONFIDENTIAL” on the top of that page and the submission should clearly indicate, via brackets, highlighting, or other means, the specific information that is business confidential. A filer requesting business confidential treatment must certify that the information is business confidential and would not customarily be released to the public by the submitter. Filers of submissions containing business confidential information also must submit a public version of their comments. The file name of the public version should begin with the character “P”. Follow the “BCI” and “P” with the name of the person or entity submitting the comments. Filers submitting comments containing no BCI should name their file using the name of the person or entity submitting the comments.</P>
                <P>
                    As noted, USTR strongly urge submitters to file comments through 
                    <E T="03">Regulations.gov</E>
                    . You must make arrangements for any alternative method of submission with Rachel Hasandras at 
                    <E T="03">Rachel.B.Hasandras@ustr.eop.gov</E>
                     in advance of the relevant deadline and before transmitting a comment.
                </P>
                <P>
                    You can find general information about USTR at 
                    <E T="03">www.ustr.gov.</E>
                </P>
                <P>
                    USTR will post comments in the docket for public inspection, except properly designated BCI. You can view comments on 
                    <E T="03">Regulations.gov</E>
                     by entering the docket number in the search field on the home page.
                </P>
                <SIG>
                    <NAME>Laura Buffo,</NAME>
                    <TITLE>Chair of the Trade Policy Staff Committee, Office of the United States Trade Representative.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17138 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 3390-F4-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">DEPARTMENT OF TRANSPORTATION</AGENCY>
                <SUBAGY>Federal Aviation Administration</SUBAGY>
                <DEPDOC>[Docket Number: FAA-2024-2081]</DEPDOC>
                <SUBJECT>Agency Information Collection Activities: Requests for Comments; Clearance of Renewed Approval of Information Collection: Airport Noise Compatibility Planning</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Federal Aviation Administration (FAA), DOT.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice and request for comments.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>In accordance with the Paperwork Reduction Act of 1995, the Federal Aviation Administration (FAA) invites public comments about our intention to request the Office of Management and Budget's (OMB) approval to renew an information collection. The collection involves information on voluntary airport noise compatibility programs. The information to be collected is necessary because noise compatibility program measures are eligible for Federal grants in-aid if they are provided to FAA for review and approval in advance. The respondents are airport sponsors/operators that voluntarily submit noise exposure maps and noise compatibility programs to the FAA for review and approval.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Written comments should be submitted by October 4, 2024.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Interested persons are invited to submit written comments on the proposed information collection to the Office of Information and Regulatory Affairs, Office of Management and Budget. Comments should be addressed to the attention of the Desk Officer, Department of Transportation/FAA. Comments can be submitted by electronic mail to 
                        <E T="03">oirasubmission@omb.eop.gov</E>
                         or by the following additional options:
                    </P>
                    <P>
                        <E T="03">By Electronic Docket: www.regulations.gov</E>
                         (Enter docket number into search field).
                    </P>
                    <P>
                        <E T="03">By mail to:</E>
                         The Office of Information and Regulatory Affairs, Office of Management and Budget, Docket Library, Room 10102, 725 17th Street NW, Washington, DC 20503 or
                    </P>
                    <P>
                        <E T="03">By fax to:</E>
                         202-395-6974.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Susan Staehle by electronic mail at: 
                        <E T="03">susan.staehle@faa.gov</E>
                         or by phone at: 202-267-7935.
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P/>
                <P>
                    <E T="03">Public Comments Invited:</E>
                     You are asked to comment on any aspect of this information collection, including (a) Whether the proposed collection of 
                    <PRTPAGE P="63467"/>
                    information is necessary for FAA's performance; (b) the accuracy of the estimated burden; (c) ways for FAA to enhance the quality, utility and clarity of the information collection; and (d) ways that the burden could be minimized 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">OMB Control Number:</E>
                     2120-0517.
                </P>
                <P>
                    <E T="03">Title:</E>
                     Airport Noise Compatibility Planning.
                </P>
                <P>
                    <E T="03">Form Numbers:</E>
                     There are no FAA forms associated with this collection.
                </P>
                <P>
                    <E T="03">Type of Review:</E>
                     Renewal of an Information Collection.
                </P>
                <P>
                    <E T="03">Background:</E>
                     The voluntarily submitted information from the current collection process pursuant to Tile 14 Code of Federal Regulations (CFR) part 150, (
                    <E T="03">e.g.,</E>
                     airport noise exposure maps and airport noise compatibility programs, or their revisions) is used by the FAA to conduct reviews of the submissions to determine if an airport sponsor's noise compatibility program is eligible for Federal grant funds. If airport sponsors did not voluntarily submit noise exposure maps and noise compatibility programs for FAA review and approval, the airport sponsor would not be eligible for the set aside of discretionary grant funds.
                </P>
                <P>
                    <E T="03">Respondents:</E>
                     Approximately 15 airport sponsors.
                </P>
                <P>
                    <E T="03">Frequency:</E>
                     Information is collected on occasion.
                </P>
                <P>
                    <E T="03">Estimated Average Burden per Response:</E>
                     2,080 hours.
                </P>
                <P>
                    <E T="03">Estimated Total Annual Burden:</E>
                     31,200 hours.
                </P>
                <SIG>
                    <DATED>Issued in: Washington, DC, July 30, 2024.</DATED>
                    <NAME>Susan Staehle,</NAME>
                    <TITLE>Environmental Protection Specialist, Office of Airports, Planning and Environmental Division, APP-400.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17134 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4910-13-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF TRANSPORTATION</AGENCY>
                <SUBAGY>Federal Railroad Administration</SUBAGY>
                <DEPDOC>[Docket Number FRA-2022-0098]</DEPDOC>
                <SUBJECT>Brightline Trains Florida's Request To Amend Its Positive Train Control Safety Plan and Positive Train Control System</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Federal Railroad Administration (FRA), Department of Transportation (DOT).</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of availability and request for comments.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>This document provides the public with notice that, on May 29, 2024, and July 19, 2024, Brightline Trains Florida (BLF) submitted a request for amendment (RFA) to its FRA-approved Positive Train Control Safety Plan (PTCSP). As this RFA involves a request for FRA's approval of proposed material modifications to an FRA-certified positive train control (PTC) system, FRA is publishing this notice and inviting public comment on the railroad's RFA to its PTCSP.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>FRA will consider comments received by August 26, 2024. FRA may consider comments received after that date to the extent practicable and without delaying implementation of valuable or necessary modifications to a PTC system.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P/>
                    <P>
                        <E T="03">Comments:</E>
                         Comments may be submitted by going to 
                        <E T="03">https://www.regulations.gov</E>
                         and following the online instructions for submitting comments.
                    </P>
                    <P>
                        <E T="03">Instructions:</E>
                         All submissions must include the agency name and the applicable docket number. The relevant PTC docket number for this host railroad is Docket No. FRA-2022-0098. For convenience, all active PTC dockets are hyperlinked on FRA's website at 
                        <E T="03">https://railroads.dot.gov/research-development/program-areas/train-control/ptc/railroads-ptc-dockets.</E>
                         All comments received will be posted without change to 
                        <E T="03">https://www.regulations.gov;</E>
                         this includes any personal information.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Gabe Neal, Staff Director, Signal, Train Control, and Crossings Division, telephone: 816-516-7168, email: 
                        <E T="03">Gabe.Neal@dot.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>In general, title 49 United States Code (U.S.C.) section 20157(h) requires FRA to certify that a host railroad's PTC system complies with title 49 Code of Federal Regulations (CFR) part 236, subpart I, before the technology may be operated in revenue service. Before making certain changes to an FRA-certified PTC system or the associated FRA-approved PTCSP, a host railroad must submit, and obtain FRA's approval of, an RFA to its PTCSP under 49 CFR 236.1021.</P>
                <P>
                    Under 49 CFR 236.1021(e), FRA's regulations provide that FRA will publish a notice in the 
                    <E T="04">Federal Register</E>
                     and invite public comment in accordance with 49 CFR part 211, if an RFA includes a request for approval of a material modification of a signal or train control system. Accordingly, this notice informs the public that, on May 29, 2024, BLF submitted an RFA to its PTCSP for its Interoperable Electronic Train Management System (I-ETMS), which seeks FRA's approval of BLF's request to implement I-ETMS Protect 7.0.3.0 which allows for the details of the fixed high-speed consist to be modifiable in the onboard computer configuration files. This change is necessary as BLF is planning to add passenger cars in order to operate high speed trains with a consist of 2 locomotives with more than 4 passenger cars. On July 19, 2024, BLF submitted the pertinent software release notes, which are a required element of an RFA to a PTCSP under 49 CFR 236.1021(m). BLF's completed RFA is available in Docket No. FRA-2022-0098.
                </P>
                <P>
                    Interested parties are invited to comment on BLF's RFA to its PTCSP by submitting written comments or data. During FRA's review of this railroad's RFA, FRA will consider any comments or data submitted within the timeline specified in this notice and to the extent practicable, without delaying implementation of valuable or necessary modifications to a PTC system. 
                    <E T="03">See</E>
                     49 CFR 236.1021; 
                    <E T="03">see also</E>
                     49 CFR 236.1011(e). Under 49 CFR 236.1021, FRA maintains the authority to approve, approve with conditions, or deny a railroad's RFA to its PTCSP at FRA's sole discretion.
                </P>
                <HD SOURCE="HD1">Privacy Act Notice</HD>
                <P>
                    In accordance with 49 CFR 211.3, FRA solicits comments from the public to better inform its decisions. DOT posts these comments, without edit, including any personal information the commenter provides, to 
                    <E T="03">https://www.regulations.gov,</E>
                     as described in the system of records notice (DOT/ALL-14 FDMS), which can be reviewed at 
                    <E T="03">https://www.transportation.gov/privacy.</E>
                     See 
                    <E T="03">https://www.regulations.gov/privacy-notice</E>
                     for the privacy notice of 
                    <E T="03">regulations.gov.</E>
                     To facilitate comment tracking, we encourage commenters to provide their name, or the name of their organization; however, submission of names is completely optional. If you wish to provide comments containing proprietary or confidential information, please contact FRA for alternate submission instructions.
                </P>
                <SIG>
                    <P>Issued in Washington, DC.</P>
                    <NAME>Carolyn R. Hayward-Williams,</NAME>
                    <TITLE>Director, Office of Railroad Systems and Technology.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17135 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4910-06-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <PRTPAGE P="63468"/>
                <AGENCY TYPE="S">DEPARTMENT OF TRANSPORTATION</AGENCY>
                <SUBAGY>Federal Railroad Administration</SUBAGY>
                <DEPDOC>[Docket No. FRA-2024-0013]</DEPDOC>
                <SUBJECT>Proposed Agency Information Collection Activities; Comment Request</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Federal Railroad Administration (FRA), Department of Transportation (DOT).</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>Under the Paperwork Reduction Act of 1995 (PRA) and its implementing regulations, FRA seeks approval of the Information Collection Request (ICR) summarized below. Before submitting this ICR to the Office of Management and Budget (OMB) for approval, FRA is soliciting public comment on specific aspects of the activities identified in the ICR.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Interested persons are invited to submit comments on or before October 4, 2024.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Written comments and recommendations for the proposed ICR should be submitted on 
                        <E T="03">regulations.gov</E>
                         to the docket, Docket No. FRA-2024-0013. All comments received will be posted without change to the docket, including any personal information provided. Please refer to the assigned OMB control number (2130-0635) in any correspondence submitted. FRA will summarize comments received in a subsequent 30-day notice and include them in its information collection submission to OMB.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Ms. Arlette Mussington, Information Collection Clearance Officer, at email: 
                        <E T="03">arlette.mussington@dot.gov</E>
                         or telephone: (571) 609-1285 or Ms. Joanne Swafford, Information Collection Clearance Officer, at email: 
                        <E T="03">joanne.swafford@dot.gov</E>
                         or telephone: (757) 897-9908.
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    The PRA, 44 U.S.C. 3501-3520, and its implementing regulations, 5 CFR part 1320, require Federal agencies to provide 60 days' notice to the public to allow comment on information collection activities before seeking OMB approval of the activities. 
                    <E T="03">See</E>
                     44 U.S.C. 3506, 3507; 5 CFR 1320.8 through 1320.12. Specifically, FRA invites interested parties to comment on the following ICR regarding: (1) whether the information collection activities are necessary for FRA to properly execute its functions, including whether the activities will have practical utility; (2) the accuracy of FRA's estimates of the burden of the information collection activities, including the validity of the methodology and assumptions used to determine the estimates; (3) ways for FRA to enhance the quality, utility, and clarity of the information being collected; and (4) ways for FRA to minimize the burden of information collection activities on the public, including the use of automated collection techniques or other forms of information technology. 
                    <E T="03">See</E>
                     44 U.S.C. 3506(c)(2)(A); 5 CFR 1320.8(d)(1).
                </P>
                <P>
                    FRA believes that soliciting public comment may reduce the administrative and paperwork burdens associated with the collection of information that Federal regulations mandate. In summary, comments received will advance three objectives: (1) reduce reporting burdens; (2) organize information collection requirements in a “user-friendly” format to improve the use of such information; and (3) accurately assess the resources expended to retrieve and produce information requested. 
                    <E T="03">See</E>
                     44 U.S.C. 3501.
                </P>
                <P>The summary below describes the ICR that FRA will submit for OMB clearance as the PRA requires:</P>
                <P>
                    <E T="03">Title:</E>
                     Report of Railroad Trespasser Form.
                </P>
                <P>
                    <E T="03">OMB Control Number:</E>
                     2130-0635.
                </P>
                <P>
                    <E T="03">Abstract:</E>
                     Trespasser deaths on railroad rights-of-way and other railroad property are the leading cause of fatalities attributable to railroad operations in the United States. To address this serious issue, the railroad industry, governments (Federal, State, and local), and other interested parties must know more about the individuals who trespass and causes. With such knowledge, specific educational programs, materials, and messages regarding the hazards and consequences of trespassing on railroad property can be developed and effectively distributed. Due to the lack of available root cause data, FRA collects data from law enforcement agencies to develop general descriptions of the root causes of trespassing. This allows FRA and other interested parties, such as Operation Lifesaver, to target audiences with appropriate education and enforcement campaigns to reduce the resulting annual number of injuries and fatalities.
                </P>
                <P>Completion and submission of form FRA F 6180.178, Report of Railroad Trespasser Form, is required for law enforcement agency grantees as a condition of FRA's Railroad Trespassing Enforcement Grant. Grantees complete the form for each trespasser incident in their jurisdiction, describing the trespassers' race/ethnicity, gender, and age to the best of their ability. For law enforcement agencies that do not receive FRA's Railroad Trespassing Enforcement grants, completion and submission of this form is voluntary.</P>
                <P>FRA provides an electronic option where the respondents can respond via a web-based form. The web-based form also helps FRA maintain the data collected in a more useful and uniform manner, as the dropdown boxes facilitate more standardized responses.</P>
                <P>
                    In this 60-day notice, FRA made adjustments that reduced the previously approved burden hours from 550 hours to 350 hours. The decrease in burden is a result of the average time per response being reduced from 10 minutes to 8 minutes to provide a more accurate analysis of the time needed to complete the form. Additionally, FRA has updated form FRA F 6180.178 to comply with OMB's recent Statistical Policy Directive No. 15, Standards for Maintaining, Collecting, and Presenting Federal Data on Race and Ethnicity (SPD 15).
                    <SU>1</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         
                        <E T="03">Spd15revision.gov.</E>
                    </P>
                </FTNT>
                <P>
                    <E T="03">Type of Request:</E>
                     Extension without change (with changes in estimates) of a currently approved information collection.
                </P>
                <P>
                    <E T="03">Affected Public:</E>
                     Public authorities.
                </P>
                <P>
                    <E T="03">Form(s):</E>
                     FRA F 6180.178.
                </P>
                <P>
                    <E T="03">Respondent Universe:</E>
                     Law enforcement agencies.
                </P>
                <P>
                    <E T="03">Frequency of Submission:</E>
                     Monthly.
                    <PRTPAGE P="63469"/>
                </P>
                <GPOTABLE COLS="6" OPTS="L2(,0,),nj,p7,7/8,i1" CDEF="s100,r100,xs60,12,12,18">
                    <TTITLE>Reporting Burden</TTITLE>
                    <BOXHD>
                        <CHED H="1">Form</CHED>
                        <CHED H="1">Respondent universe</CHED>
                        <CHED H="1">
                            Total annual
                            <LI>responses</LI>
                        </CHED>
                        <CHED H="1">
                            Average time
                            <LI>per response</LI>
                            <LI>(minutes)</LI>
                        </CHED>
                        <CHED H="1">
                            Total annual
                            <LI>burden hours</LI>
                        </CHED>
                        <CHED H="1">
                            Total cost
                            <LI>equivalent</LI>
                        </CHED>
                    </BOXHD>
                    <ROW RUL="s">
                        <ENT I="25"> </ENT>
                        <ENT O="xl"/>
                        <ENT>(A)</ENT>
                        <ENT>(B)</ENT>
                        <ENT>(C = A * B)</ENT>
                        <ENT>
                            (D = C *
                            <LI>
                                wage rate) 
                                <SU>2</SU>
                            </LI>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Report of Railroad Trespasser Form (Form FRA F 6180.178)</ENT>
                        <ENT>Law enforcement agencies, grantees</ENT>
                        <ENT>2,500 forms</ENT>
                        <ENT>8</ENT>
                        <ENT>333.30</ENT>
                        <ENT>$20,184.65</ENT>
                    </ROW>
                    <ROW RUL="n,n,n,s">
                        <ENT I="22"> </ENT>
                        <ENT>Law enforcement agencies, non-grantees</ENT>
                        <ENT>100 forms</ENT>
                        <ENT>10</ENT>
                        <ENT>16.70</ENT>
                        <ENT>1,011.35</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">
                            Total 
                            <SU>3</SU>
                        </ENT>
                        <ENT>Law enforcement agencies</ENT>
                        <ENT>2,600 responses</ENT>
                        <ENT>N/A</ENT>
                        <ENT>350</ENT>
                        <ENT>21,196</ENT>
                    </ROW>
                </GPOTABLE>
                <P>
                    <E T="03">Total Estimated Annual Responses:</E>
                     2,600.
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>2</SU>
                         Source: U.S. Department of Labor, Bureau of Labor Statistics (BLS) Employer Cost for Employee Compensation—December 2023 for State and local government. The hourly wage rate used is $37.53 + overhead of 38%. Total burdened wage rate is $60.56 ($37.53 + $23.03).
                    </P>
                    <P>
                        <SU>3</SU>
                         Totals may not add up due to rounding.
                    </P>
                </FTNT>
                <P>
                    <E T="03">Total Estimated Annual Burden:</E>
                     350 hours.
                </P>
                <P>
                    <E T="03">Total Estimated Annual Burden Hour Dollar Cost Equivalent:</E>
                     $21,196.
                </P>
                <P>FRA informs all interested parties that it may not conduct or sponsor, and a respondent is not required to respond to, a collection of information that does not display a currently valid OMB control number.</P>
                <P>
                    <E T="03">Authority:</E>
                     44 U.S.C. 3501-3520.
                </P>
                <SIG>
                    <NAME>Christopher S. Van Nostrand,</NAME>
                    <TITLE>Deputy Chief Counsel.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17189 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4910-06-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF TRANSPORTATION</AGENCY>
                <SUBAGY>Federal Railroad Administration</SUBAGY>
                <DEPDOC>[Docket No. FRA-2024-0014]</DEPDOC>
                <SUBJECT>Proposed Agency Information Collection Activities; Comment Request</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Federal Railroad Administration (FRA), Department of Transportation (DOT).</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>Under the Paperwork Reduction Act of 1995 (PRA) and its implementing regulations, FRA seeks approval of the Information Collection Request (ICR) summarized below. Before submitting this ICR to the Office of Management and Budget (OMB) for approval, FRA is soliciting public comment on specific aspects of the activities identified in the ICR.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Interested persons are invited to submit comments on or before October 4, 2024.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Written comments and recommendations for the proposed ICR should be submitted on 
                        <E T="03">regulations.gov</E>
                         to the docket, Docket No. FRA-2024-0014. All comments received will be posted without change to the docket, including any personal information provided. Please refer to the assigned OMB control number (2130-0505) in any correspondence submitted. FRA will summarize comments received in a subsequent 30-day notice and include them in its information collection submission to OMB.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Ms. Arlette Mussington, Information Collection Clearance Officer, at email: 
                        <E T="03">arlette.mussington@dot.gov</E>
                         or telephone: (571) 609-1285 or Ms. Joanne Swafford, Information Collection Clearance Officer, at email: 
                        <E T="03">joanne.swafford@dot.gov</E>
                         or telephone: (757) 897-9908.
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    The PRA, 44 U.S.C. 3501-3520, and its implementing regulations, 5 CFR part 1320, require Federal agencies to provide 60 days' notice to the public to allow comment on information collection activities before seeking OMB approval of the activities. 
                    <E T="03">See</E>
                     44 U.S.C. 3506, 3507; 5 CFR 1320.8 through 1320.12. Specifically, FRA invites interested parties to comment on the following ICR regarding: (1) whether the information collection activities are necessary for FRA to properly execute its functions, including whether the activities will have practical utility; (2) the accuracy of FRA's estimates of the burden of the information collection activities, including the validity of the methodology and assumptions used to determine the estimates; (3) ways for FRA to enhance the quality, utility, and clarity of the information being collected; and (4) ways for FRA to minimize the burden of information collection activities on the public, including the use of automated collection techniques or other forms of information technology. 
                    <E T="03">See</E>
                     44 U.S.C. 3506(c)(2)(A); 5 CFR 1320.8(d)(1).
                </P>
                <P>
                    FRA believes that soliciting public comment may reduce the administrative and paperwork burdens associated with the collection of information that Federal regulations mandate. In summary, comments received will advance three objectives: (1) reduce reporting burdens; (2) organize information collection requirements in a “user-friendly” format to improve the use of such information; and (3) accurately assess the resources expended to retrieve and produce information requested. 
                    <E T="03">See</E>
                     44 U.S.C. 3501.
                </P>
                <P>The summary below describes the ICR that FRA will submit for OMB clearance as the PRA requires:</P>
                <P>
                    <E T="03">Title:</E>
                     Inspection and Maintenance of Steam Locomotives.
                </P>
                <P>
                    <E T="03">OMB Control Number:</E>
                     2130-0505.
                </P>
                <P>
                    <E T="03">Abstract:</E>
                     The Locomotive Inspection Act (LIA) establishes safety and inspection requirements for locomotives in “use” on a “railroad line.” 
                    <SU>1</SU>
                    <FTREF/>
                     The statute was first enacted in 1911 as part of a broad congressional effort to “reduce the loss of life and the injuries” caused by the dangerous conditions that prevailed on the railroads in the late 19th and early 20th centuries.
                    <SU>2</SU>
                    <FTREF/>
                     In 1911, Congress enacted the first iteration of the LIA to address the harms posed by locomotive boilers,
                    <SU>3</SU>
                    <FTREF/>
                     making it “unlawful” for a common carrier “to use any locomotive engine propelled by steam power in moving interstate or foreign traffic unless the boiler of said locomotive and appurtenances thereof are in proper condition and safe to operate in the service to which the same is put.” 
                    <SU>4</SU>
                    <FTREF/>
                     To help ensure the locomotive boilers and their appurtenances are in proper condition, the Steam Locomotive Inspection and Maintenance Standards require certain boiler pressure 
                    <PRTPAGE P="63470"/>
                    calculations and service-day inspections to be recorded and available to FRA.
                    <SU>5</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         49 U.S.C. 20701 
                        <E T="03">et seq.</E>
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>2</SU>
                         
                        <E T="03">Johnson</E>
                         v. 
                        <E T="03">Southern Pac. Co.,</E>
                         196 U.S. 1, 19 (1904); see 
                        <E T="03">Napier</E>
                         v. 
                        <E T="03">Atlantic Coast Line R.R.,</E>
                         272 U.S. 605, 607-608 (1926).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>3</SU>
                         Act of Feb. 17, 1911 (Act of 1911), ch. 103, 36 Stat. 913 (known as the Boiler Inspection Act).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>4</SU>
                         Act of 1911, sec. 2, 36 Stat. 913-914.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>5</SU>
                         49 CFR part 230.
                    </P>
                </FTNT>
                <P>In this 60-day notice FRA has made adjustments that decreased the previously approved burden hours from 1,357 hours to 1,049 hours. The decrease in burden hours is the result of a more accurate analysis of the number of forms FRA F 1 and FRA F 3 that are required to be posted in the locomotive cab. Additionally, the burden hours being reported under 49 CFR 230.41 for the removal of flexible stay bolt caps on form FRA F 3 is already included in the average time of 30 minutes reported to complete each form. Therefore, the burden hours for this requirement have been removed.</P>
                <P>
                    <E T="03">Type of Request:</E>
                     Extension without change (with changes in estimates) of a currently approved collection.
                </P>
                <P>
                    <E T="03">Affected Public:</E>
                     Businesses.
                </P>
                <P>
                    <E T="03">Form(s):</E>
                     FRA F 1, FRA F 2, FRA F 3, FRA F 4, FRA F 5, and FRA F 19.
                </P>
                <P>
                    <E T="03">Respondent Universe:</E>
                     82 steam locomotive owners/operators.
                </P>
                <P>
                    <E T="03">Frequency of Submission:</E>
                     On occasion; annually.
                </P>
                <GPOTABLE COLS="7" OPTS="L2(,0,),p7,7/8,i1" CDEF="s100,r50,9,9,12,9,12">
                    <TTITLE>Reporting Burden</TTITLE>
                    <BOXHD>
                        <CHED H="1">CFR part 230 section/FRA form name and number</CHED>
                        <CHED H="1">Respondent universe</CHED>
                        <CHED H="1">
                            Annual
                            <LI>responses</LI>
                        </CHED>
                        <CHED H="1">
                            Average
                            <LI>time per</LI>
                            <LI>response</LI>
                            <LI>(hours)</LI>
                        </CHED>
                        <CHED H="1">Total annual burden hours</CHED>
                        <CHED H="1">
                            Wage
                            <LI>rate</LI>
                        </CHED>
                        <CHED H="1">
                            Total cost
                            <LI>equivalent</LI>
                            <LI>U.S.D.</LI>
                        </CHED>
                    </BOXHD>
                    <ROW RUL="s">
                        <ENT I="25"> </ENT>
                        <ENT O="xl"/>
                        <ENT>(A)</ENT>
                        <ENT>(B)</ENT>
                        <ENT>(A * B = C)</ENT>
                        <ENT>
                            (D) 
                            <SU>6</SU>
                        </ENT>
                        <ENT>(E = C * D)</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22">FRA F 1:</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">31 and 92 Service Day Inspection Report</ENT>
                        <ENT>82 steam owners operators</ENT>
                        <ENT>480</ENT>
                        <ENT>0.33</ENT>
                        <ENT>160.00</ENT>
                        <ENT>89.13</ENT>
                        <ENT>$14,260.80</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22">FRA F 2:</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Daily Locomotive Inspection Report</ENT>
                        <ENT>82 steam owners operators</ENT>
                        <ENT>3,650</ENT>
                        <ENT>0.17</ENT>
                        <ENT>608.33</ENT>
                        <ENT>89.13</ENT>
                        <ENT>54,220.45</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22">FRA F 3:</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Annual Inspection Report</ENT>
                        <ENT>82 steam owners operators</ENT>
                        <ENT>115</ENT>
                        <ENT>0.5</ENT>
                        <ENT>57.50</ENT>
                        <ENT>89.13</ENT>
                        <ENT>5,124.98</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22">FRA F 4:</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Boiler Specification Card</ENT>
                        <ENT>82 steam owners operators</ENT>
                        <ENT>12</ENT>
                        <ENT>0.5</ENT>
                        <ENT>6.00</ENT>
                        <ENT>89.13</ENT>
                        <ENT>534.78</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22">FRA F 5:</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Locomotive Service Day Report</ENT>
                        <ENT>82 steam owners operators</ENT>
                        <ENT>150</ENT>
                        <ENT>0.25</ENT>
                        <ENT>37.50</ENT>
                        <ENT>89.13</ENT>
                        <ENT>3,342.38</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22">FRA F 19:</ENT>
                    </ROW>
                    <ROW RUL="n,s">
                        <ENT I="03">Report of Alteration or Welded or Riveted Repair</ENT>
                        <ENT>82 steam owners/operators</ENT>
                        <ENT>10</ENT>
                        <ENT>1</ENT>
                        <ENT>10.00</ENT>
                        <ENT>89.13</ENT>
                        <ENT>891.30</ENT>
                    </ROW>
                    <ROW RUL="s">
                        <ENT I="05">Forms Subtotal</ENT>
                        <ENT/>
                        <ENT>4,417</ENT>
                        <ENT/>
                        <ENT>879.33</ENT>
                        <ENT/>
                        <ENT>78,374.68</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22">230.6—Waivers:</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">(a)—Waivers</ENT>
                        <ENT/>
                        <ENT>1</ENT>
                        <ENT>1.00</ENT>
                        <ENT>1.00</ENT>
                        <ENT>89.13</ENT>
                        <ENT>89.13</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22">230.12—Movement of non-complying steam locomotives:</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">(b)—Conditions for movement (tagging)</ENT>
                        <ENT>82 steam owners/ operators</ENT>
                        <ENT>10</ENT>
                        <ENT>0.10</ENT>
                        <ENT>1.00</ENT>
                        <ENT>69.60</ENT>
                        <ENT>69.60</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22">230.14—Thirty-one (31) service day inspection:</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">(b)—FRA notification of 31 service day inspection</ENT>
                        <ENT>82 steam owners/operators</ENT>
                        <ENT>360</ENT>
                        <ENT>0.08</ENT>
                        <ENT>30.00</ENT>
                        <ENT>89.13</ENT>
                        <ENT>2,673.90</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22">230.16—Annual inspection:</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">(b)—FRA notification of annual inspection</ENT>
                        <ENT>82 steam owners/operators</ENT>
                        <ENT>120</ENT>
                        <ENT>0.08</ENT>
                        <ENT>10.00</ENT>
                        <ENT>89.13</ENT>
                        <ENT>891.30</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22">230.19—Posting of FRA Form No. 1 and FRA Form No. 3:</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">(a) and (b)—Posting of forms</ENT>
                        <ENT>82 steam owners/operators</ENT>
                        <ENT>662</ENT>
                        <ENT>0.08</ENT>
                        <ENT>52.96</ENT>
                        <ENT>89.13</ENT>
                        <ENT>4,720.32</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22">230.21—Steam locomotive number change:</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">—Number change</ENT>
                        <ENT>82 steam owners/operators</ENT>
                        <ENT>1</ENT>
                        <ENT>0.03</ENT>
                        <ENT>0.03</ENT>
                        <ENT>89.13</ENT>
                        <ENT>2.67</ENT>
                    </ROW>
                    <ROW RUL="s">
                        <ENT I="22">230.22—Accident reports:</ENT>
                    </ROW>
                    <ROW EXPSTB="06" RUL="s">
                        <ENT I="21">
                            <E T="03">The burden hours associated with this requirement are included OMB Control No. 2130-0500. Consequently, there is no additional burden associated with this requirement.</E>
                        </ENT>
                    </ROW>
                    <ROW EXPSTB="00">
                        <ENT I="22">230.33—Welded repairs and alterations:</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">(a)—Written requests to FRA</ENT>
                        <ENT>82 steam owners/operators</ENT>
                        <ENT>8</ENT>
                        <ENT>2.00</ENT>
                        <ENT>16.00</ENT>
                        <ENT>89.13</ENT>
                        <ENT>1,426.08</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22">230.34—Riveted repairs and alterations:</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">(a)—Written requests</ENT>
                        <ENT>82 steam owners/operators</ENT>
                        <ENT>2</ENT>
                        <ENT>2.00</ENT>
                        <ENT>4.00</ENT>
                        <ENT>89.13</ENT>
                        <ENT>356.52</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22">230.46—Badge plates:</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">—Attaching of metal badge plate</ENT>
                        <ENT>82 steam owners/operators</ENT>
                        <ENT>3</ENT>
                        <ENT>2.00</ENT>
                        <ENT>6.00</ENT>
                        <ENT>69.60</ENT>
                        <ENT>417.60</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22">230.47—Boiler number:</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">(a)—Stamped boiler number</ENT>
                        <ENT>82 steam owners/operators</ENT>
                        <ENT>1</ENT>
                        <ENT>1.00</ENT>
                        <ENT>1.00</ENT>
                        <ENT>69.60</ENT>
                        <ENT>69.60</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22">230.49—Setting of safety relief valves:</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">(d)—Labeling of lowest set pressure</ENT>
                        <ENT/>
                        <ENT>5</ENT>
                        <ENT>1.00</ENT>
                        <ENT>5.00</ENT>
                        <ENT>69.60</ENT>
                        <ENT>348.00</ENT>
                    </ROW>
                    <ROW RUL="s">
                        <ENT I="22">230.60—Time of washing:</ENT>
                    </ROW>
                    <ROW EXPSTB="06" RUL="s">
                        <ENT I="21">
                            <E T="03">The burden for this requirement is included above in the burden listed under §§ 230.15 and 230.16. Consequently, there is no additional burden associated with this requirement.</E>
                        </ENT>
                    </ROW>
                    <ROW EXPSTB="00">
                        <ENT I="22">230.75—Stenciling dates of tests and cleaning:</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">—Stenciling</ENT>
                        <ENT>82 steam owners/operators</ENT>
                        <ENT>50</ENT>
                        <ENT>0.50</ENT>
                        <ENT>25.00</ENT>
                        <ENT>69.60</ENT>
                        <ENT>1,740.00</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22">230.96—Main, side, and valve motion rods:</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">(b)—Written request for repairs</ENT>
                        <ENT>82 steam owners/operators</ENT>
                        <ENT>1</ENT>
                        <ENT>2.00</ENT>
                        <ENT>2.00</ENT>
                        <ENT>89.13</ENT>
                        <ENT>178.26</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22">230.98 Driving, trailing, and engine truck axles:</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">(b)—Journal diameter stamped</ENT>
                        <ENT>82 steam owners/operators</ENT>
                        <ENT>1</ENT>
                        <ENT>0.25</ENT>
                        <ENT>0.25</ENT>
                        <ENT>69.60</ENT>
                        <ENT>17.40</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22">230.116—Oil tanks:</ENT>
                    </ROW>
                    <ROW RUL="n,s">
                        <ENT I="03">—Marking of hand operated locations</ENT>
                        <ENT>82 steam owners/operators</ENT>
                        <ENT>30</ENT>
                        <ENT>0.50</ENT>
                        <ENT>15.00</ENT>
                        <ENT>69.60</ENT>
                        <ENT>1,044.00</ENT>
                    </ROW>
                    <ROW RUL="n,s">
                        <ENT I="05">Subtotal</ENT>
                        <ENT/>
                        <ENT>1,255</ENT>
                        <ENT/>
                        <ENT>169.24</ENT>
                        <ENT/>
                        <ENT>14,044.39</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="07">
                            Total
                            <SU>7</SU>
                        </ENT>
                        <ENT>82 steam owners/operators</ENT>
                        <ENT>5,672</ENT>
                        <ENT>N/A</ENT>
                        <ENT>1,049</ENT>
                        <ENT>N/A</ENT>
                        <ENT>92,419</ENT>
                    </ROW>
                </GPOTABLE>
                <PRTPAGE P="63471"/>
                <P>
                    <E T="03">Total Estimated Annual</E>
                     Responses: 5,672.
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>6</SU>
                         The dollar equivalent cost is derived from the 2023 Surface Transportation Board Full Year Wage A&amp;B data series using the employee group 200 (Professional &amp; Administrative) hourly wage rate of $50.93 and group 400 (Maintenance of Equipment &amp; Stores) hourly wage rate of $39.77. The total burden wage rate (Straight time plus 75%) used in the table is $89.13 ($50.93 × 1.75 = $89.13), and $69.60 ($39.77 × 1.75 = $69.60).
                    </P>
                    <P>
                        <SU>7</SU>
                         Totals may not add up due to rounding.
                    </P>
                </FTNT>
                <P>
                    <E T="03">Total Estimated Annual Burden:</E>
                     1,049 hours.
                </P>
                <P>
                    <E T="03">Total Estimated Annual Burden Hour Dollar Cost Equivalent:</E>
                     $92,419.
                </P>
                <P>FRA informs all interested parties that it may not conduct or sponsor, and a respondent is not required to respond to, a collection of information that does not display a currently valid OMB control number.</P>
                <P>
                    <E T="03">Authority:</E>
                     44 U.S.C. 3501-3520.
                </P>
                <SIG>
                    <NAME>Christopher S. Van Nostrand,</NAME>
                    <TITLE>Deputy Chief Counsel.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17186 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4910-06-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF TRANSPORTATION</AGENCY>
                <SUBAGY>Federal Railroad Administration</SUBAGY>
                <DEPDOC>[Docket Number FRA-2015-0062]</DEPDOC>
                <SUBJECT>Florida East Coast Railway's Request To Amend Its Positive Train Control Safety Plan and Positive Train Control System</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Federal Railroad Administration (FRA), Department of Transportation (DOT).</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of availability and request for comments.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>This document provides the public with notice that, on June 4, 2024, and July 22, 2024, Florida East Coast Railway (FECR) submitted a request for amendment (RFA) to its FRA-approved Positive Train Control Safety Plan (PTCSP). As this RFA involves a request for FRA's approval of proposed material modifications to an FRA-certified positive train control (PTC) system, FRA is publishing this notice and inviting public comment on the railroad's RFA to its PTCSP.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>FRA will consider comments received by August 26, 2024. FRA may consider comments received after that date to the extent practicable and without delaying implementation of valuable or necessary modifications to a PTC system.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P/>
                    <P>
                        <E T="03">Comments:</E>
                         Comments may be submitted by going to 
                        <E T="03">https://www.regulations.gov</E>
                         and following the online instructions for submitting comments.
                    </P>
                    <P>
                        <E T="03">Instructions:</E>
                         All submissions must include the agency name and the applicable docket number. The relevant PTC docket number for this host railroad is Docket No. FRA-2015-0062. For convenience, all active PTC dockets are hyperlinked on FRA's website at 
                        <E T="03">https://railroads.dot.gov/research-development/program-areas/train-control/ptc/railroads-ptc-dockets.</E>
                         All comments received will be posted without change to 
                        <E T="03">https://www.regulations.gov;</E>
                         this includes any personal information.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Gabe Neal, Staff Director, Signal, Train Control, and Crossings Division, telephone: 816-516-7168, email: 
                        <E T="03">Gabe.Neal@dot.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>In general, title 49 United States Code (U.S.C.) section 20157(h) requires FRA to certify that a host railroad's PTC system complies with title 49 Code of Federal Regulations (CFR) part 236, subpart I, before the technology may be operated in revenue service. Before making certain changes to an FRA-certified PTC system or the associated FRA-approved PTCSP, a host railroad must submit, and obtain FRA's approval of, an RFA to its PTCSP under 49 CFR 236.1021.</P>
                <P>
                    Under 49 CFR 236.1021(e), FRA's regulations provide that FRA will publish a notice in the 
                    <E T="04">Federal Register</E>
                     and invite public comment in accordance with 49 CFR part 211, if an RFA includes a request for approval of a material modification of a signal or train control system. Accordingly, this notice informs the public that, on June 4, 2024, FECR submitted an RFA to its PTCSP for its Interoperable Electronic Train Management System (I-ETMS), which seeks FRA's approval of FECR's request to implement I-ETMS Protect 7.0.3.0 which allows for the details of the fixed high-speed consist to be modifiable in the onboard computer configuration files. This change supports Brightline Trains Florida's plan to add passenger cars in order to operate high speed trains with a consist of 2 locomotives with more than 4 passenger cars. On July 22, 2024, FECR submitted the pertinent software release notes, which are a required element of an RFA to a PTCSP under 49 CFR 236.1021(m). FECR's completed RFA is available in Docket No. FRA-2015-0062.
                </P>
                <P>
                    Interested parties are invited to comment on FECR's RFA to its PTCSP by submitting written comments or data. During FRA's review of this railroad's RFA, FRA will consider any comments or data submitted within the timeline specified in this notice and to the extent practicable, without delaying implementation of valuable or necessary modifications to a PTC system. 
                    <E T="03">See</E>
                     49 CFR 236.1021; 
                    <E T="03">see also</E>
                     49 CFR 236.1011(e). Under 49 CFR 236.1021, FRA maintains the authority to approve, approve with conditions, or deny a railroad's RFA to its PTCSP at FRA's sole discretion.
                </P>
                <HD SOURCE="HD1">Privacy Act Notice</HD>
                <P>
                    In accordance with 49 CFR 211.3, FRA solicits comments from the public to better inform its decisions. DOT posts these comments, without edit, including any personal information the commenter provides, to 
                    <E T="03">https://www.regulations.gov,</E>
                     as described in the system of records notice (DOT/ALL-14 FDMS), which can be reviewed at 
                    <E T="03">https://www.transportation.gov/privacy.</E>
                     See 
                    <E T="03">https://www.regulations.gov/privacy-notice</E>
                     for the privacy notice of 
                    <E T="03">regulations.gov.</E>
                     To facilitate comment tracking, we encourage commenters to provide their name, or the name of their organization; however, submission of names is completely optional. If you wish to provide comments containing proprietary or confidential information, please contact FRA for alternate submission instructions.
                </P>
                <SIG>
                    <P>Issued in Washington, DC.</P>
                    <NAME>Carolyn R. Hayward-Williams,</NAME>
                    <TITLE>Director, Office of Railroad Systems and Technology.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17136 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4910-06-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF TRANSPORTATION</AGENCY>
                <SUBAGY>Federal Railroad Administration</SUBAGY>
                <DEPDOC>[Docket No. FRA-2024-0083]</DEPDOC>
                <SUBJECT>Request for Information on Collaboration and Data Sharing for Railroad Operations Analysis</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Federal Railroad Administration (FRA), Department of Transportation (DOT).</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Request for information (RFI).</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>
                        On November 15, 2021, President Biden signed into law the Infrastructure Investment and Jobs Act, also known as the Bipartisan Infrastructure Law (BIL). The BIL provides historic appropriations for railroad transportation grant programs administered by the Federal Railroad Administration (FRA) and authorizes new programs to enhance rail safety and to repair, restore, improve, and expand the nation's rail network. Among those new programs is the Corridor 
                        <PRTPAGE P="63472"/>
                        Identification and Development Program (CID Program), which creates a new framework to facilitate the development of new, enhanced, and restored intercity passenger rail corridors throughout the country. Railroad Operations Analysis (OA) uses data to assess changes to railroad operations and/or capital project improvements to railroad infrastructure and is frequently part of the planning process for rail projects. OA involves the collaboration of various rail stakeholders and the sharing of data and information. As a result of the CID Program, there is an increased need for FRA and rail stakeholders to participate in OA and evaluate OA results. FRA finds value in conducting OA in a collaborative manner to promote increased confidence in the OA among stakeholders and support Federal FRA investments in infrastructure projects. In this RFI, FRA seeks public comments on the challenges involved in OA, how FRA may address those challenges, and how FRA may improve OA for Federally funded railroad projects.
                    </P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Written comments on this RFI must be received on or before September 19, 2024. FRA may consider comments filed after this date to the extent practicable.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Comments should refer to docket number FRA-2024-0083 and be submitted by at 
                        <E T="03">https://www.regulations.gov.</E>
                         Search by using the docket number and follow the instructions for submitting comments.
                    </P>
                    <P>
                        <E T="03">Instructions:</E>
                         All submissions must include the agency name and docket number for this RFI.
                    </P>
                </ADD>
                <NOTE>
                    <HD SOURCE="HED">Note:</HD>
                    <P>
                         All comments received, including any personal information, will be posted without change to the docket and will be accessible to the public at 
                        <E T="03">https://www.regulations.gov.</E>
                         You should not include information in your comment that you do not want to be made public. Input submitted online via 
                        <E T="03">www.regulations.gov</E>
                         is not immediately posted to the site. It may take several business days before your submission is posted.
                    </P>
                </NOTE>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                         For further information concerning this notice, please contact the FRA Office of Railroad Development staff via email at 
                        <E T="03">PAXRAILDEV@dot.gov.</E>
                         If additional assistance is needed, you may contact Bryan Bertoli, Community Planner, at email 
                        <E T="03">bryan.bertoli@dot.gov</E>
                         or telephone: 405-406-5575; Eric Pihl, Transportation Industry Analyst, at email: 
                        <E T="03">eric.pihl@dot.gov</E>
                         or telephone: 303-594-3559; in FRA's Office of Railroad Development.
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">Background</HD>
                <P>
                    For purposes of this RFI, Railroad OA means the analytical process for identifying and testing means for achieving operational objectives based on assumptions regarding, and hypothetical variations to, the infrastructure, characteristics of train movements, and the conditions under which those train movements operate. Operational objectives for an OA may include, but are not limited to, the introduction of a new rail service; the expansion of an existing rail service (
                    <E T="03">e.g.,</E>
                     the operation of additional service frequencies or trains); changes in train characteristics (
                    <E T="03">e.g.,</E>
                     length, horsepower per ton, etc.); changes to stops made by trains en route (
                    <E T="03">e.g.,</E>
                     at stations, shipper facilities, or yards); and improvements to the operational performance of an existing service (
                    <E T="03">e.g.,</E>
                     through a reduction in travel times and/or improvements to operational reliability).
                </P>
                <P>FRA involvement in OA may include funding, overseeing, and participating in project planning and project development studies for the improvement of railroad service, particularly intercity passenger rail service, throughout the country, and funding the implementation of the railroad capital investments identified through those studies.</P>
                <P>OA, when conducted for projects in which FRA is involved, frequently involves the collaboration of different participants with varying roles, interests, and priorities.</P>
                <P>
                    OA participants include FRA, Project Sponsors,
                    <SU>1</SU>
                    <FTREF/>
                     owners and operators of railroad facilities, and consultants acting on behalf of these entities. There are also individuals and organizations that may have an interest in the OA results for federally-funded projects but do not directly participate in the development of OA.
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         “Project Sponsor means the entity responsible for implementing a capital project that may also be an applicant seeking or a grantee receiving federal financial assistance.” 
                        <E T="03">FRA Guidance on Development and Implementation of Railroad Capital Projects</E>
                         (Jan. 11, 2023) at page 3, 
                        <E T="03">available at https://railroads.dot.gov/elibrary/fra-guidance-development-and-implementation-railroad-capital-project.</E>
                    </P>
                </FTNT>
                <P>
                    OA is an important means for assessing options for capital improvements to railroad facilities (
                    <E T="03">e.g.,</E>
                     main line track and signal improvements, station configuration, etc.), as well as potential changes to railroad operations. These alterations to railroad capital improvements and/or operations can represent a major portion of the overall cost of a railroad development project. These alterations may also contribute to a project's environmental impacts, which are initially considered during the project planning stage and continue to be assessed through the National Environmental Policy Act (NEPA) process. For example, project planning elements specifically include environmental resource consideration and resilience planning.
                    <SU>2</SU>
                    <FTREF/>
                     OA results paired with environmental resource consideration may inform which preliminary project alternatives are identified and then developed based on the project's purpose and need. After the completion of the project planning stage, preliminary project alternatives are advanced into project development stage activities, which may include environmental review required under NEPA.
                </P>
                <FTNT>
                    <P>
                        <SU>2</SU>
                         
                        <E T="03">See id.</E>
                         at 6.
                    </P>
                </FTNT>
                <P>
                    Generally, the Project Sponsor, or a consultant acting on behalf of the Project Sponsor, will use tools, such as train performance calculators and railroad operations simulation software, to generate OA outputs. Software used for operations modeling requires the integration of existing and proposed conditions relevant to the analysis, referred to as input data. Input data includes train movement information and infrastructure information. Train movement information reflects physical and operational characteristics of trains that have a direct effect on their performance and includes but is not limited to: number of trains operating over the subject territory broken down by general train type; average operating characteristics of trains by train type (
                    <E T="03">e.g.,</E>
                     length, horsepower per ton, etc.); specific operating timetables for scheduled services (
                    <E T="03">e.g.,</E>
                     including passenger and employee timetables); significant time-specific requirements for unscheduled services; detailed historical movement information; and the recommended Compound Annual Growth Rate by train type.
                </P>
                <P>
                    Infrastructure information is data that captures the physical characteristics of the geographic territory being analyzed and is necessary for OA. Engineering track charts are referenced as these typically include information such as signals, platforms, bridges, and grade crossings. Infrastructure information collected for OA includes documentation of other relevant transportation projects under development or in the process of implementation within the study area. Significantly, the infrastructure input data used for OA will directly determine how trains can operate over the subject territory.
                    <PRTPAGE P="63473"/>
                </P>
                <P>
                    Based on a specific set of train movement and infrastructure inputs for a given case, OA outputs can capture the way in which trains move over the subject territory and include train-specific metrics that allow for evaluation of operational performance and reliability. OA output data includes but is not limited to: train performance calculator outputs; time-distance diagrams; tabular results of operational performance metrics with description of variables calibrated for the OA (
                    <E T="03">e.g.,</E>
                     locomotive performance); proposed infrastructure improvements under analyzed scenarios, including existing, no-action, and action scenarios; and native OA software files of both inputs and outputs.
                </P>
                <P>
                    Access to the underlying information supporting an OA (
                    <E T="03">i.e.,</E>
                     input and output data) is essential for understanding the OA model itself and the results it produces. Moreover, access to OA data allows stakeholders, including FRA, to understand the nature of existing and proposed future railroad operations and to better assess the feasibility of Federally funded transportation investments and projects. Access to OA data also supports a more collaborative OA approach, allows stakeholders to have greater confidence in the OA model and output, and may reduce disputes related to OA data that can increase the time and costs for a railroad project.
                </P>
                <HD SOURCE="HD1">Information Requested</HD>
                <P>FRA seeks to ensure that the creative and problem-solving process at the core of OA is as effective and collaborative as possible. As such, with the questions below, FRA is requesting public comment to gain a better understanding of the potential challenges involved in the development of OA and the review of OA results to assess what improvements can be made for Federally funded railroad projects. Respondents to this RFI are encouraged to consider the full range of railroad development efforts in which FRA may be involved or otherwise support, including, but not limited to intercity passenger rail development projects. FRA requests that responses include, as applicable, a reference to the numbered questions. Respondents are also encouraged to address in their responses any topics they believe to be relevant and are not limited to addressing the questions listed below.</P>
                <P>1. What challenges and issues have you experienced with the development of OA?</P>
                <P>2. What challenges and issues have you experienced with the review of OA results for Federally funded projects?</P>
                <P>3. What type of assistance from FRA would be beneficial for the development of OA?</P>
                <P>4. Have you experienced any challenges or issues that limit access to OA data? Please explain.</P>
                <P>5. How do you suggest FRA encourage data sharing for OA?</P>
                <P>6. What roles and responsibilities should participants undertake to promote a collaborative OA?</P>
                <P>7. What factors contribute to the success of a collaborative OA?</P>
                <P>8. In the absence of access to all data inputs required for an OA, are there alternative methods or means to obtain sufficient information to conduct an OA or review OA results?</P>
                <P>9. Please share any other additional feedback or comments on OA and/or data sharing.</P>
                <P>FRA will review responses to this RFI to better understand challenges involved in OA by responsive parties. FRA will determine how and whether FRA may address those challenges, and what further steps FRA should take with respect to OA.</P>
                <HD SOURCE="HD1">Privacy Act Statement</HD>
                <P>
                    FRA notes that anyone is able to search (at 
                    <E T="03">https://www.regulations.gov</E>
                    ) the electronic form of all filings received into any of DOT's dockets by the name of the individual submitting the filing (or signing the filing, if submitted on behalf of an association, business, labor union, or other organization). You may review DOT's complete Privacy Act Statement published in the 
                    <E T="04">Federal Register</E>
                     on April 11, 2000 (65 FR 19476), or you may view the privacy notice of regulations.gov at 
                    <E T="03">https://www.regulations.gov/privacy-notice.</E>
                </P>
                <SIG>
                    <P>Issued in Washington, DC.</P>
                    <NAME>Paul Nissenbaum,</NAME>
                    <TITLE>Associate Administrator, Office of Railroad Development.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17185 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4910-06-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF TRANSPORTATION</AGENCY>
                <SUBAGY>National Highway Traffic Safety Administration</SUBAGY>
                <DEPDOC>[Docket No. NHTSA-2023-0038]</DEPDOC>
                <SUBJECT>Supplemental Initial Decision That Certain Frontal Driver and Passenger Air Bag Inflators Manufactured by ARC Automotive Inc. and Delphi Automotive Systems LLC, and Vehicles in Which Those Inflators Were Installed, Contain a Safety Defect</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>National Highway Traffic Safety Administration (NHTSA), Department of Transportation (DOT).</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of supplemental initial decision; request for public comments.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>NHTSA is confirming its initial decision that certain frontal driver and passenger air bag inflators manufactured by ARC Automotive Inc. and Delphi Automotive Systems LLC, and vehicles in which those inflators were installed, contain a defect related to motor vehicle safety. NHTSA is issuing this supplemental initial decision to address in greater detail the basis for the agency's initial decision and to ensure that all vehicles and manufacturers that would be impacted by any recall order are included within the scope of the initial decision.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Comments must be received on or before September 4, 2024.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>You may submit written submissions to the docket number identified in the heading of this document by any of the following methods:</P>
                    <P>
                        • 
                        <E T="03">Federal eRulemaking Portal:</E>
                         Go to 
                        <E T="03">https://www.regulations.gov.</E>
                         Follow the online instructions for submitting comments.
                    </P>
                    <P>
                        • 
                        <E T="03">Mail:</E>
                         Docket Management Facility: U.S. Department of Transportation, 1200 New Jersey Avenue SE, West Building Ground Floor, Room W12-140, Washington, DC 20590-0001.
                    </P>
                    <P>
                        • 
                        <E T="03">Hand Delivery or Courier:</E>
                         1200 New Jersey Avenue SE, West Building Ground Floor, Room W12-140, between 9 a.m. and 5 p.m. ET, Monday through Friday, except Federal holidays.
                    </P>
                    <P>
                        • 
                        <E T="03">Fax:</E>
                         (202) 493-2251.
                    </P>
                    <P>
                        <E T="03">Instructions:</E>
                         All submissions must include the agency name and docket number. Note that all written submissions received will be posted without change to 
                        <E T="03">https://www.regulations.gov,</E>
                         including any personal information provided. Please see the Privacy Act discussion below. We will consider all written submissions received before the close of business on September 4, 2024.
                    </P>
                    <P>
                        <E T="03">Docket:</E>
                         For access to the docket to read background documents or written submissions received, go to 
                        <E T="03">https://www.regulations.gov</E>
                         at any time or to 1200 New Jersey Avenue SE, West Building Ground Floor, Room W12-140, Washington, DC 20590, between 9 a.m. and 5 p.m., Monday through Friday, except Federal holidays. Telephone 202-366-9826.
                    </P>
                    <P>
                        <E T="03">Privacy Act:</E>
                         In accordance with 49 U.S.C. 30118(b)(1), NHTSA will make a final decision only after providing an opportunity for manufacturers and any interested person to present information, views, and arguments. DOT posts written submissions submitted by manufacturers and 
                        <PRTPAGE P="63474"/>
                        interested persons, without edit, including any personal information the submitter provides, to 
                        <E T="03">www.regulations.gov,</E>
                         as described in the system of records notice (DOT/ALL-14 Federal Docket Management System (FDMS)), which can be reviewed at 
                        <E T="03">www.transportation.gov/privacy.</E>
                    </P>
                    <P>
                        <E T="03">Confidential Business Information:</E>
                         If you wish to submit any information under a claim of confidentiality, you must submit your request directly to NHTSA's Office of the Chief Counsel. Requests for confidentiality are governed by 49 CFR part 512. NHTSA is currently treating electronic submission as an acceptable method for submitting confidential business information (CBI) to the agency under part 512. If you would like to submit a request for confidential treatment, you may email your submission to Allison Hendrickson in the Office of the Chief Counsel at 
                        <E T="03">allison.hendrickson@dot.gov</E>
                         or you may contact her for a secure file transfer link. At this time, you should not send a duplicate hardcopy of your electronic CBI submissions to DOT headquarters. If you claim that any of the information or documents provided to the agency constitute confidential business information within the meaning of 5 U.S.C. 552(b)(4) or are protected from disclosure pursuant to 18 U.S.C. 1905, you must submit supporting information together with the materials that are the subject of the confidentiality request, in accordance with part 512, to the Office of the Chief Counsel. Your request must include a cover letter setting forth the information specified in NHTSA's confidential business information regulation (49 CFR 512.8) and a certificate, pursuant to § 512.4(b) and part 512, appendix A. In addition, you should submit a copy, from which you have redacted the claimed confidential business information, to the Docket at the address given above.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Allison Hendrickson, Office of the Chief Counsel, National Highway Traffic Safety Administration, 1200 New Jersey Avenue SE, Washington, DC 20590; (202) 366-2992.</P>
                    <P>
                        The publicly available information on which this supplemental initial decision is based is available on the agency's website at 
                        <E T="03">https://www.nhtsa.gov/recalls?nhtsaId=EA16003, https://www.nhtsa.gov/recalls?nhtsaId=PE15027,</E>
                         and on the public docket under Docket No. NHTSA-2023-0038.
                    </P>
                    <P>The information in the investigative file for which confidential treatment has been requested was shared with the manufacturers that would be affected in the event of a recall order, as required under 49 U.S.C. 30118(a) and 49 CFR 554.10(b). That information was shared with the manufacturers under a protective agreement. The information subject to confidentiality requests remains unredacted in this document pursuant to 49 U.S.C. 30167(b). File-path citations to the investigative file have been shared with the manufacturers in a confidential appendix to this decision.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>Pursuant to 49 U.S.C. 30118(a) and 49 CFR 554.10, NHTSA confirms its initial decision that certain frontal driver and passenger air bag inflators manufactured by ARC Automotive Inc. (ARC) and Delphi Automotive Systems LLC (Delphi), and vehicles in which those inflators were installed, contain a defect related to motor vehicle safety.</P>
                <P>
                    NHTSA previously issued an initial decision on September 5, 2023.
                    <SU>1</SU>
                    <FTREF/>
                     After additional consideration of the totality of the evidence, including comments previously submitted in this proceeding, NHTSA is issuing this supplemental initial decision to address in greater detail the basis for the agency's initial decision and to ensure that all vehicles and vehicle manufacturers that would be impacted by any recall order are included within the scope of the initial decision. This action allows for additional transparency and additional comment from any interested persons.
                    <SU>2</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         88 FR 62140 (Sept. 8, 2023).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>2</SU>
                         NHTSA is addressing certain comments in this supplemental initial decision to describe the basis of its initial decision more fully and, in certain instances, to update certain information, including its calculation of predicted future ruptures. NHTSA reviewed and considered all written and oral comments previously submitted in this proceeding. NHTSA intends to further and more fully address all comments it ultimately receives if and when it issues a final decision in this proceeding.
                    </P>
                </FTNT>
                <P>
                    The additional information provided in this notice confirms the agency's initial decision that certain frontal driver- and passenger-side hybrid toroidal air bag inflators manufactured by ARC and Delphi from 2000 through the full implementation of the automated borescope (the subject inflators) contain a defect related to motor vehicle safety. The implementation of the borescope, beginning in August of 2017, was fully completed in June of 2018. The latter date is a correction from the January 2018 completion date identified in the September 5, 2023 initial decision.
                    <SU>3</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>3</SU>
                         ARC completed implementation of the automated borescope process on lines producing PH7 inflators (which are passenger-side inflators) in January 2018, and then completed implementation on the remaining lines producing toroidal inflators in June 2018.
                    </P>
                </FTNT>
                <P>
                    Based on available information, approximately 51 million subject inflators were manufactured and installed in approximately 49 million vehicles in the United States.
                    <SU>4</SU>
                    <FTREF/>
                     The subject inflators were incorporated into air bag modules manufactured by five air bag module suppliers and ultimately used in vehicles manufactured by 13 vehicle manufacturers: BMW of North America, LLC (BMW), FCA US LLC (FCA), Ford Motor Company (Ford), General Motors LLC (GM), Hyundai Motor America, Inc. (Hyundai), Jaguar Land Rover North America (JLR), LLC, Kia America, Inc. (Kia), Maserati North America, Inc., Mercedes-Benz USA LLC, Porsche Cars North America, Inc. (Porsche), Tesla Inc., Toyota Motor North America, Inc. (Toyota), and Volkswagen Group of America, Inc. (Volkswagen).
                    <SU>5</SU>
                    <FTREF/>
                     Although JLR was not included in the September 2023 initial decision, the agency has confirmed that it has vehicles in the U.S. with the subject inflators.
                </P>
                <FTNT>
                    <P>
                        <SU>4</SU>
                         While the correction to June 2018 increases the number of subject inflators, based on best available information, the agency is adjusting its estimate to approximately 51 million inflators. The exact number of recalled inflators and vehicles would be confirmed by the manufacturers as part of any recall filings that may result.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>5</SU>
                         In the event of a recall order, BMW would be responsible for recalling vehicles manufactured by Rolls Royce Motor Cars, General Motors would be responsible for recalling vehicles manufactured by Isuzu Motors Limited, and Volkswagen would be responsible for recalling vehicles manufactured by Audi AG.
                    </P>
                </FTNT>
                <P>
                    These air bag inflators are at risk of rupturing when the vehicle's air bag is commanded to deploy, causing metal debris to be forcefully ejected into the occupant compartment of the vehicle. A rupturing air bag inflator poses an unreasonable risk of serious injury or death to vehicle occupants. At least seven people have been injured and one person has been killed by these rupturing air bag inflators within the United States. NHTSA has identified evidence during its investigation that connects these ruptures to the friction welding process, which has created, in some instances, blockage material, including excessive weld flash, and, in others, insufficient friction weld bonds. Upon air bag deployment, any loose debris in the center support, including weld flash, can block the exit orifice, causing over-pressurization and rupture. Additionally, friction welds with insufficient bonds have also led to inflator ruptures. The same friction welding process was used across ARC and Delphi's various manufacturing plants and lines to produce the subject inflators. When an inflator ruptures, shrapnel or metal fragments from the 
                    <PRTPAGE P="63475"/>
                    inflator are forcefully propelled through the air bag cushion and into the occupant compartment. Additional inflator ruptures are expected to occur in the future, risking more serious injuries and deaths, if they are not recalled and replaced.
                </P>
                <HD SOURCE="HD1">I. Investigation and Proceeding Background</HD>
                <P>On July 13, 2015, NHTSA's Office of Defects Investigation (ODI) opened a Preliminary Evaluation (PE) defect investigation, designated PE15-027, to investigate an alleged safety defect in hybrid toroidal inflators designed by ARC and manufactured by ARC and Delphi for use in vehicles sold or leased in the United States. NHTSA opened the investigation after receiving reports of ruptures in vehicles (field ruptures). Specifically, driver-side air bag inflators in a model year (MY) 2002 Chrysler Town &amp; Country and a MY 2004 Kia Optima ruptured upon air bag deployment during crashes.</P>
                <P>
                    In the early stages of the investigation, NHTSA collected information from ARC regarding the design and manufacturing process for frontal driver- and passenger-side hybrid toroidal inflators. Frontal driver-side and passenger-side inflators are used to inflate air bags immediately in front of vehicle occupants in those seats. A hybrid inflator uses stored gas that is excited by propellant to fill the air bag cushion, and toroidal inflators are round, non-cylindrical inflators. NHTSA's investigation involved both single-stage and dual-stage inflators. Single-stage inflators deploy at a preset speed and at full force. Dual-stage inflators deploy at two different stages depending on the size of the occupant as measured by the load sensor in the front seat and the severity of the impact.
                    <SU>6</SU>
                    <FTREF/>
                     ARC licensed its design and manufacturing specifications to Delphi, which manufactured approximately 11 million of the approximate 51 million subject inflators using the same friction welding process at issue.
                    <SU>7</SU>
                    <FTREF/>
                     ARC manufactured the other subject inflators at several different manufacturing facilities.
                </P>
                <FTNT>
                    <P>
                        <SU>6</SU>
                         The two inflation stages can deploy sequentially or simultaneously. Typically, the first stage is approximately 80% of the full force of the air bag, and the second stage is approximately 20% of the full force of the air bag. The second stage can deploy simultaneously with the first stage should the severity of the impact warrant dual deployment. The second stage can deploy subsequent to the deployment of the first stage for lower severity impacts.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>7</SU>
                         Delphi stopped manufacturing the inflators in 2004. The Delphi entity that manufactured these inflators no longer exists. NHTSA indicated in its April 27, 2023 recall request letter that the entity was acquired by Autoliv ASP, Inc. (“Autoliv”). Autoliv has since provided NHTSA with some information indicating that it may not have legal liability for the Delphi-manufactured inflators. At this time, NHTSA has not verified the entity that has legal responsibility under 49 U.S.C. chapter 301 for those inflators. However, regardless of that responsibility, the vehicle manufacturers that used the inflators as original equipment would be responsible for carrying out any recalls.
                    </P>
                </FTNT>
                <P>
                    NHTSA learned that, based on ARC's inflator design, part of the manufacturing process for these inflators involves a welding method known as friction welding. Through this method, once certain pieces of the inflator are ready to be joined together, they are aligned. One piece is held stationary while the other is rotated at a high velocity and simultaneously pressed together with the stationary piece. The friction generated by the high-velocity rotation creates heat, which melts the metal. Once the proper temperature has been reached, the rotation is stopped, and the pressure is increased to weld the parts together. Each inflator undergoes three friction welds at two points in the manufacturing process.
                    <SU>8</SU>
                    <FTREF/>
                     Friction welding produces a byproduct called “weld flash” or “weld slag” that accumulates along the weld seam. In an attempt to prevent weld flash from blocking the gas flow during deployment, a pin, known as a flash-dam pin, is inserted through the exit orifice during the friction welding process between the center support and upper half of the inflator housing. The flash-dam pin is removed after the weld is complete. This friction welding process was used in all five ARC plants where the subject inflators were made—located in Knoxville, Tennessee; Reynosa, Mexico; Xi'an, China; Ningbo, China; and Skopje, Macedonia—and on all manufacturing lines that produced the subject inflators. It was also used by Delphi when it produced subject inflators under a license agreement.
                </P>
                <FTNT>
                    <P>
                        <SU>8</SU>
                         
                        <E T="03">See</E>
                         ARC Presentation on CADH Inflator Design; ARC Presentation on PH7 Inflator Process Details.
                    </P>
                </FTNT>
                <P>
                    During a crash that triggers an air bag deployment, a signal is sent to the inflator. When it receives this signal, the inflator's initiator ignites the propellant that is stored inside the inflator.
                    <SU>9</SU>
                    <FTREF/>
                     The propellant burns and excites pressurized gas stored in the inflator.
                    <SU>10</SU>
                    <FTREF/>
                     To fill the air bag cushion, the gas flows through the inflator's hollow center support and exits through the exit orifice at the top of the center support.
                    <SU>11</SU>
                    <FTREF/>
                     The inflator's exit orifice is the single path for the gas to exit the inflator and fill the air bag cushion. If the exit orifice is blocked during deployment such that the gas cannot escape, the inflator will likely over-pressurize and rupture. In this event, the center support typically elongates, splits into two pieces, and ejects from the inflator housing. These characteristics indicate that a rupture was caused by over-pressurization of the inflator.
                    <SU>12</SU>
                    <FTREF/>
                     In some instances, the blockage can still be seen in the upper half of the center support after the rupture. In others, the blockage may become knocked loose by the force of the rupture but can leave small indentations on the edge of the exit orifice, which are known as “witness marks.” 
                    <SU>13</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>9</SU>
                         
                        <E T="03">See</E>
                         ARC Response to Request 1 of NHTSA Aug. 25, 2015 IR Letter at p. 16.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>10</SU>
                         
                        <E T="03">See id.</E>
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>11</SU>
                         
                        <E T="03">See id.</E>
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>12</SU>
                         
                        <E T="03">See</E>
                         ARC Presentation dated Mar. 1, 2016 on MY 2004 Kia Optima Rupture at pp. 5, 22; ARC Presentation dated Aug. 25, 2017 on SGO 2016-01/2017-01 Report 39 at pp. 6, 11, 37; ARC Response to Request 1 of NHTSA Aug. 25, 2015 IR Letter at p. 72.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>13</SU>
                         
                        <E T="03">See</E>
                         ARC Presentation dated Apr. 1, 2017 on SGO 2016-01/2017-01 Report 80 at pp. 8-11; ARC Presentation dated Nov. 10, 2017 on SGO 2016-01/2017-01 Report 120 at p. 7; ARC Presentation dated Apr. 5, 2017 on SGO 2016-01/2017-01 Report 130 at pp. 8-11; ARC Presentation dated Nov. 8, 2017 on SGO 2016-01/2017-01 Report 178 at pp. 13-14.
                    </P>
                </FTNT>
                <P>
                    During the PE phase of the investigation, NHTSA collected a list of air bag module (or Tier 1) manufacturers to which ARC sold the inflators from 2000 through 2004, which covered the timeframe between when ARC had begun manufacturing hybrid toroidal inflators and the manufacture dates of the two inflators that ruptured in vehicles. NHTSA then obtained information from the air bag module manufacturers to identify the vehicle manufacturers that had purchased those air bag modules and incorporated them into their vehicles. In addition, NHTSA ordered vehicle and inflator manufacturers, including ARC, to report any alleged or suspected inflator field rupture under Standing General Orders (SGO) 2015-01 and 2015-02.
                    <SU>14</SU>
                    <FTREF/>
                     Manufacturers subject to these orders must submit an initial report upon notification of an alleged field rupture incident, as well as ongoing supplemental reports as the investigation into the incident progresses and until it is complete.
                </P>
                <FTNT>
                    <P>
                        <SU>14</SU>
                         Those orders were not limited to ARC or the vehicle manufacturers that used ARC inflators. They were intended to help NHTSA learn of any alleged inflator ruptures, including inflators not designed or manufactured by ARC. Since their original issuance, these orders have been updated and superseded by SGO 2015-01A and SGO 2015-02A. 
                        <E T="03">https://static.nhtsa.gov/odi/inv/2015/INLM-EA15001-62640.pdf; https://static.nhtsa.gov/odi/inv/2015/INLM-EA15001-62642.pdf.</E>
                    </P>
                </FTNT>
                <P>
                    On July 11, 2016, an ARC-manufactured inflator in a MY 2009 Hyundai Elantra ruptured in Canada. The driver was killed. ARC confirmed that this inflator was manufactured using the same manufacturing processes 
                    <PRTPAGE P="63476"/>
                    described above in this section. ODI upgraded the investigation to an Engineering Analysis, designated EA16-003, on August 4, 2016. During this phase of the investigation, ODI issued information request letters to ARC, Delphi, air bag module manufacturers, and vehicle manufacturers in 2016, 2020, 2021, and 2022. These letters requested information for an expanded timeframe on the production volume of the subject inflators, air bag modules with the subject inflators and vehicles with the subject inflators, testing procedures and results, complaints, and air bag deployments.
                </P>
                <P>
                    Also during this phase of the investigation, NHTSA issued Standing General Order 2016-01. Standing General Order 2016-01 required ARC to notify the agency of non-field ruptures of inflators. It was superseded by SGO 2017-01, which revised the reportable rupture incidents to include only those occurring during lot acceptance tests. Lot acceptance tests (also referred to as “LATs”) are random tests of completed air bag inflators produced for use in consumer vehicles.
                    <SU>15</SU>
                    <FTREF/>
                     If an inflator ruptures or fails in some way during a lot acceptance test, the entire lot of inflators is quarantined. Under these SGOs, ARC reported thirty-four ruptures of frontal driver- and passenger-side hybrid toroidal inflators during lot acceptance testing.
                    <SU>16</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>15</SU>
                         A lot acceptance test is conducted at the beginning, middle, and end of a manufacturing shift, or at any time the assembly line is shifted to production of a different part. The term “lot” refers to the inflators that were manufactured in an identified manufacturing plant on a specific assembly line for a specific shift.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>16</SU>
                         Two vehicle manufacturers have conducted small inflator recalls associated with lot acceptance testing. First, BMW recalled thirty-six vehicles after learning that the production lot in which there had been a rupture was not fully contained, and some inflators from the lot were shipped by ARC to a module supplier and ultimately were incorporated into vehicles. NHTSA Recall Nos. 17V-189 (describing the safety risk as “impaired gas flow could create excessive internal pressure, which could result in the body of the inflator rupturing upon deployment”). Second, Ford recalled 650 vehicles after its air bag module supplier notified Ford of “an abnormal deployment” of an inflator during a lot acceptance test at the supplier's engineering facility. NHTSA Recall Nos. 17V-529 (“Preliminary analysis indicates that weld flash from the inflator canister welding process at the Tier 2 inflator supplier may obstruct the gas exhaust port.”).
                    </P>
                </FTNT>
                <P>
                    ARC's lot acceptance testing process evidenced a problem, but the problem was not addressed by actions limited to specific lots. Since NHTSA issued SGOs 2015-01 and 2015-02, manufacturers have reported to the agency and confirmed five ruptures in vehicles in the United States of ARC-manufactured frontal driver- and passenger-side hybrid toroidal inflators, for a total of seven confirmed field ruptures in the United States, plus the fatal rupture in Canada. In response to some of the field ruptures, the relevant vehicle manufacturer issued a small recall targeted at the production lot of the ruptured inflator.
                    <SU>17</SU>
                    <FTREF/>
                     Such recalls, like the quarantine process for lot acceptance test ruptures, are premised on the idea that there is some sort of manufacturing problem limited to that short period of production at that particular facility. As detailed below, however, the evidence collected in NHTSA's investigation shows that ruptures have occurred in inflators manufactured across different time periods, plants, and manufacturing lines, thus warranting a broader recall.
                </P>
                <FTNT>
                    <P>
                        <SU>17</SU>
                         
                        <E T="03">See</E>
                         NHTSA Recall Nos. 19V-019 (recalling 1,145 vehicles), 21V-782 (recalling 555 vehicles), 22E-040 (recalling 74 replacement air bag modules), 22V-246 (recalling 2,687 vehicles), and 22V-543 (recalling 1,216 vehicles). Following the most recent rupture, GM also expanded on its earlier lot recalls by recalling four model years of three vehicle makes. NHTSA Recall No 23V-334.
                    </P>
                </FTNT>
                <P>
                    In a recall request letter sent to ARC on April 27, 2023, the agency tentatively concluded that the subject inflators present a defect related to motor vehicle safety.
                    <SU>18</SU>
                    <FTREF/>
                     NHTSA explained that a defect resulting in metal fragments being projected toward vehicle occupants creates an unreasonable risk of death and injury.
                    <SU>19</SU>
                    <FTREF/>
                     The agency, therefore, demanded that ARC file a recall identifying the subject inflators as defective.
                    <SU>20</SU>
                    <FTREF/>
                     In its response on May 11, 2023, ARC described the seven U.S. field ruptures as “random `one-off' manufacturing anomalies” that had been properly addressed by the lot recalls.
                    <SU>21</SU>
                    <FTREF/>
                     ARC refused to acknowledge the safety defect or file a recall.
                    <SU>22</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>18</SU>
                         
                        <E T="03">See</E>
                         NHTSA Recall Request Letter to ARC, 
                        <E T="03">https://static.nhtsa.gov/odi/inv/2016/INRM-EA16003-90615.pdf.</E>
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>19</SU>
                         
                        <E T="03">See id.</E>
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>20</SU>
                         
                        <E T="03">See id.</E>
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>21</SU>
                         
                        <E T="03">See</E>
                         ARC Response to NHTSA Recall Request Letter, 
                        <E T="03">https://static.nhtsa.gov/odi/inv/2016/INRR-EA16003-90616.pdf</E>
                         at p. 2.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>22</SU>
                         
                        <E T="03">See id.</E>
                         at p. 1.
                    </P>
                </FTNT>
                <P>
                    When a safety defect exists in original equipment used by more than one vehicle manufacturer, as in this case, the equipment supplier and each vehicle manufacturer must notify the agency by filing a recall report. 49 CFR 573.3(f). A defect in original equipment (meaning equipment originally installed in or on a vehicle) is considered a defect in the vehicle. 49 U.S.C. 30102(b)(1)(C), (F). Therefore, vehicle manufacturers are generally responsible for carrying out recalls of their vehicles containing defective parts, such as air bag inflators, by notifying vehicle owners and providing a free remedy. 
                    <E T="03">See id.</E>
                     sections 30118-20. An equipment manufacturer is also responsible under the Safety Act for recalling its replacement equipment. 
                    <E T="03">See id.</E>
                     30118. Replacement equipment is “motor vehicle equipment . . . that is not original equipment.” 
                    <E T="03">Id.</E>
                     section 30102(b)(1)(D).
                </P>
                <P>
                    The National Traffic and Motor Vehicle Safety Act (Safety Act) imposes an affirmative obligation on a manufacturer to initiate a recall if it “learns the vehicle or equipment contains a defect and decides in good faith that the defect is related to motor vehicle safety.” 
                    <E T="03">Id.</E>
                     section 30118(c)(1). To date, the manufacturers of the subject inflators, and the manufacturers of the vehicles containing the subject inflators, have not commenced broader recalls addressing the full scope of the problem. Thus, NHTSA is using its authority under the Safety Act to consider ordering a recall.
                </P>
                <P>
                    The Safety Act authorizes NHTSA to order a recall when the Administrator 
                    <SU>23</SU>
                    <FTREF/>
                     determines that a vehicle or replacement equipment “contains a defect related to motor vehicle safety.” 
                    <E T="03">Id.</E>
                     section 30118(b). The Safety Act defines a “defect” as “any defect in performance, construction, a component, or material of a motor vehicle or motor vehicle equipment.” 
                    <E T="03">Id.</E>
                     section 30102(a)(3). A defect is related to motor vehicle safety if it presents an unreasonable risk of an accident or of death or serious injury in an accident. 
                    <E T="03">Id.</E>
                     section 30102(a)(9).
                </P>
                <FTNT>
                    <P>
                        <SU>23</SU>
                         As authorized by statute, the Secretary has delegated the authority in the Safety Act to the NHTSA Administrator. 49 U.S.C. 105(d); 49 CFR 1.95(a). In the absence of an Administrator, the Deputy Administrator performs the functions and duties of the Administrator. 49 CFR 501.4(a), 501.5(a).
                    </P>
                </FTNT>
                <P>
                    Before it can order a recall, the agency first issues an initial decision finding a defect in a vehicle or replacement equipment, notifies the manufacturer of the decision and provides it with the information on which the decision was based, and publishes notice of the decision in the 
                    <E T="04">Federal Register</E>
                    . 
                    <E T="03">Id.</E>
                     section 30118(a); 49 CFR 554.10. The manufacturer and the public are afforded an opportunity to present information, views, and arguments at a public meeting, in written comments, or both. 49 CFR 554.10. After considering the available information, the Administrator may make a final decision finding a safety defect and ordering a recall. 49 U.S.C. 30118(b); 49 CFR 554.11.
                </P>
                <P>
                    In the instant proceeding, NHTSA issued an initial decision of a safety defect on September 5, 2023 regarding frontal driver- and passenger-side hybrid toroidal inflators manufactured 
                    <PRTPAGE P="63477"/>
                    by ARC and Delphi from 2000 through January 2018. 88 FR 62140 (Sept. 8, 2023). NHTSA held a public meeting on October 5, 2023, during which the agency presented information about its investigation and initial decision, and manufacturers and members of the public were invited to make their own statements.
                    <SU>24</SU>
                    <FTREF/>
                     ARC and certain other members of the public, including the son of the person killed by a subject inflator rupture, made statements at the public meeting.
                    <SU>25</SU>
                    <FTREF/>
                     NHTSA also provided manufacturers and the public the opportunity to submit written comments in response to the initial decision,
                    <SU>26</SU>
                    <FTREF/>
                     which were due December 18, 2023.
                    <SU>27</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>24</SU>
                         
                        <E T="03">See</E>
                         Public Meeting Transcript and Addenda, Docket No. NHTSA-2023-0038, 
                        <E T="03">https://www.regulations.gov/document/NHTSA-2023-0038-0003.</E>
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>25</SU>
                         
                        <E T="03">Id.</E>
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>26</SU>
                         Public versions of all written comments are posted on the public docket at 
                        <E T="03">https://www.regulations.gov/docket/NHTSA-2023-0038/comments.</E>
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>27</SU>
                         
                        <E T="03">See</E>
                         Second Extension of Deadline for Written Submissions, 
                        <E T="03">https://www.regulations.gov/document/NHTSA-2023-0038-0005.</E>
                    </P>
                </FTNT>
                <HD SOURCE="HD1">II. Initial Determination of Defect Related to Motor Vehicle Safety</HD>
                <P>After further consideration of all available information, including from its investigation and this proceeding, NHTSA is confirming its initial determination that the subject inflators contain a defect and that the defect is related to motor vehicle safety. The subject inflators may rupture upon deployment and project shrapnel into the occupant compartment, which is likely to cause and has caused serious injury and death to vehicle occupants.</P>
                <HD SOURCE="HD2">A. The Subject Inflators Are Defective</HD>
                <P>
                    Air bag inflators that have an established risk of rupturing when commanded to deploy are defective within the meaning of the Safety Act. The Safety Act defines “defect” as including “any defect in performance, construction, a component, or material of a motor vehicle or motor vehicle equipment.” 49 U.S.C. 30102(a)(3). “Defect” must be understood by its plain meaning: a flaw, shortcoming, or abnormality.
                    <SU>28</SU>
                    <FTREF/>
                     An inflator that is at risk of rupturing when commanded to deploy is flawed. It turns a lifesaving device into one that can do great harm, including causing death or serious injury.
                </P>
                <FTNT>
                    <P>
                        <SU>28</SU>
                         
                        <E T="03">https://www.merriam-webster.com/dictionary/defect.</E>
                    </P>
                </FTNT>
                <P>
                    Air bags and related components can be defective in multiple ways. Among other things, the air bag may fail to deploy when appropriate, deploy when it should not, or only partially deploy. All of these defects are issues that the agency takes seriously and that have resulted in recalls.
                    <SU>29</SU>
                    <FTREF/>
                     An air bag inflator that has a risk of rupturing when commanded to deploy—sending shrapnel into the occupant compartment—presents a particularly dangerous type of defect. This is why the industry standard calls for tests to confirm that “an inflator shall not eject any components or fragments.” 
                    <SU>30</SU>
                    <FTREF/>
                     In other words, an inflator rupture is not an industry-accepted failure mode.
                </P>
                <FTNT>
                    <P>
                        <SU>29</SU>
                         
                        <E T="03">See, e.g.,</E>
                         NHTSA Recall 24V-064 (recall issued by Honda addressing air bags that may deploy in a crash when they should have been suppressed); NHTSA Recall 23V-865 (recall issued by Toyota addressing air bags that may not deploy in a crash when intended); NHTSA Recall No. 12V-055 (recall issued by Nissan for vehicles equipped with curtain air bags with incorrect propellant mixture, possibly resulting in partial deployment); NHTSA Recall No. 01V-318 (recall issued by Ford for vehicles with replacement inflators having insufficient welds, possibly preventing proper inflation of the air bag).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>30</SU>
                         
                        <E T="03">See</E>
                         USCAR Inflator Technical Requirements and Validation, p. 7 ¶ 3.2.2 (SAE Int'l, 2023). 
                        <E T="03">See also</E>
                         USCAR Inflator Technical Requirements and Validation, p. 10 ¶ 3.2.2 (SAE Int'l, 2013).
                    </P>
                </FTNT>
                <P>The subject inflators exhibit this especially dangerous defect, which warrants NHTSA's taking the significant step of proposing to order a recall. To date, there have been seven confirmed field ruptures of the subject inflators in vehicles in the United States, each of which presented evidence of over-pressurization or weld insufficiency as a likely cause of the failure. In addition, there have been twenty-three reported ruptures during lot acceptance testing that share over-pressurization or weld insufficiency commonalities with the seven field ruptures. Moreover, at least an additional four inflators have ruptured in vehicles outside the United States, killing at least one person.</P>
                <P>To be sure, the overwhelming majority of the subject inflators will not rupture upon deployment. However, based on the evidence linking past ruptures to the same friction welding process, all of the subject inflators are at risk of rupturing. The unpredictable nature of this defect has played out with some inflators passing lot acceptance testing but later rupturing in a vehicle and causing injury or death. The only way to know which of the subject inflators remaining in vehicles will rupture is for them to deploy. The Safety Act does not allow such a defect to go unaddressed.</P>
                <P>
                    In recognition of the commonsense understanding that an inflator that may rupture is defective, some vehicle manufacturers have already issued limited recalls following field ruptures.
                    <SU>31</SU>
                    <FTREF/>
                     This approach is insufficient to address the defect. The evidence shows that the risk of rupture pervades the entire subject inflator population and, as such, a recall for all subject inflators is needed. Ruptures have continued to occur outside the scope of these lot-based recalls and in lots that passed lot acceptance testing. There is no reasonable basis to conclude that the recalls issued to this point have captured the full scope of the defect. Instead, NHTSA has preliminarily concluded, based on the available evidence, that all the subject inflators are defective.
                </P>
                <FTNT>
                    <P>
                        <SU>31</SU>
                         After the most recent rupture, GM apparently recognized that a lot-based recall was no longer sufficient. However, the ensuing recall was limited to specific model years and models of vehicles and fails to address the full population of GM vehicles containing the subject inflators. 
                        <E T="03">See</E>
                         Recall No. 23V-334 (recalling 2014-2017 Buick Enclave, Chevrolet Traverse, and GMC Acadia vehicles).
                    </P>
                </FTNT>
                <P>
                    Whether there is a “defect” depends on the specific facts and circumstances of each case, including the nature of the component involved and its importance to the safe operation of the vehicle, the circumstances in which failures occurred, and the number of failures experienced. 
                    <E T="03">U.S.</E>
                     v. 
                    <E T="03">General Motors Corp.,</E>
                     518 F.2d 420, 427, 438 n.84 (D.C. Cir. 1975) (“
                    <E T="03">Wheels</E>
                    ”). Considering all of the available information, NHTSA finds that there is sufficient evidence that the total population of subject inflators is defective within the meaning of the Safety Act.
                </P>
                <HD SOURCE="HD3">1. An Air Bag Is Critical to the Safe Operation of a Vehicle</HD>
                <P>
                    Factors to be considered in determining whether a defect exists include the relationship between the component and safe vehicle operation and the circumstances of the failures involved. An air bag is vital to the safe operation of a vehicle. It is a required safety device.
                    <SU>32</SU>
                    <FTREF/>
                     In the event of a crash where the air bag is commanded to deploy, which can include a minor crash, the air bag helps protect the occupant's upper body and head from impact with hard objects such as the windows, dashboard, and steering wheel. NHTSA estimates that air bags saved more than fifty thousand lives between 1987 and 2017. The defect in this case turns this life-saving purpose on its head, instead introducing a risk of serious injury or death from flying metal fragments ejected into the occupant compartment. As described below in section II.A.3, rupturing inflators have caused severe injuries, the most common of which are injuries to 
                    <PRTPAGE P="63478"/>
                    the face, head, jaw, and neck. In three instances, a piece of the inflator became lodged in the driver's neck or arm and had to be surgically removed.
                    <SU>33</SU>
                    <FTREF/>
                     In another, the shrapnel caused permanent muscle and nerve damage to the driver.
                    <SU>34</SU>
                    <FTREF/>
                     In two instances, the driver died after being struck by a piece of the inflator. By forcefully propelling metal shrapnel into the occupant compartment, often aimed directly at an occupants' face, the rupturing inflator creates a high risk of severe injury or death, potentially converting a minor crash into a life-threatening event.
                </P>
                <FTNT>
                    <P>
                        <SU>32</SU>
                         Federal Motor Vehicle Safety Standard 208 sets requirements for occupant crash protection, including air bags. 49 CFR 571.208.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>33</SU>
                         
                        <E T="03">See</E>
                         Email dated Apr. 5, 2023 to NHTSA from Hurley Medical Center; Photos attached to email dated Apr. 5, 2023 to NHTSA from Hurley Medical Center; Medical Discharge Summaries, Report ID ****8352 at p. 3; Information package provided by the Saudi Ministry of Commerce and Industry; Hyundai Report submitted for MY 2011 Hyundai Elantra Rupture.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>34</SU>
                         
                        <E T="03">See</E>
                         VOQ dated Dec. 20, 2014.
                    </P>
                </FTNT>
                <P>
                    The circumstances in which these failures occur are also severe. The ruptures occur with no warning to the driver or other vehicle occupants.
                    <SU>35</SU>
                    <FTREF/>
                     A vehicle owner can neither prevent this failure from occurring nor take action to mitigate the severity of its outcome, given the rapid pace of an air bag deployment and the already vulnerable position of the occupants in the midst of a collision. A vehicle's air bags can deploy even in minor crashes, meaning this defect can turn an incident from which the occupants could have walked away unscathed into one that will likely cause serious injury or death. There is no way for a vehicle owner, or anyone else, to know that a particular subject inflator will rupture until it is too late. The safety of vehicle occupants is significantly compromised by the rupture of the subject inflators—a considerable factor in the agency's determination that the subject inflators are defective under the Safety Act.
                </P>
                <FTNT>
                    <P>
                        <SU>35</SU>
                         Severity, frequency, and detectability are factors that NHTSA and manufacturers consider when deciding whether there is a safety defect requiring a recall. 
                        <E T="03">See Risk-Based Process for Safety Defect Analysis and Management of Recalls,</E>
                         DOT HS 812 984 (Nov. 2020), 
                        <E T="03">https://www.nhtsa.gov/sites/nhtsa.gov/files/documents/14895_odi_defectsrecallspubdoc_110520-v6a-tag.pdf.</E>
                         These factors are interrelated so high severity and non-detectible failures warrant a recall with a lower frequency of occurrence. 
                        <E T="03">See id.</E>
                    </P>
                </FTNT>
                <HD SOURCE="HD3">2. Problems That Lead to Over-Pressurization and Weld Failure May Be Present Throughout the Entire Population of Inflators</HD>
                <P>
                    While the actual occurrence of ruptures is rare, the subject inflators' risk of rupture nevertheless constitutes a defect, especially when considering the nature and purpose of an inflator and the severity of the risk to vehicle occupants. For a component that is designed to function without replacement, courts have found that a defect may be established by showing that a significant—or non-
                    <E T="03">de minimis</E>
                    —number of failures occurred in normal operation. 
                    <E T="03">E.g., Wheels,</E>
                     518 F.2d at 427, 438 n.84. As mentioned in the section above, the number of failures is one of the factors among the various facts and circumstances that assists in the agency's determination of whether there is a defect related to motor vehicle safety, requiring a recall. Indeed, “[t]he purpose of the Safety Act . . . is not to protect individuals from the risks associated with defective vehicles only after serious injuries have already occurred; it is to prevent serious injuries stemming from established defects before they occur.” 
                    <E T="03">United States</E>
                     v. 
                    <E T="03">General Motors Corp.,</E>
                     565 F.2d 754, 759 (D.C. Cir. 1977) (“
                    <E T="03">Carburetors</E>
                    ”).
                </P>
                <P>
                    Air bags are not subjected to wear and do not require maintenance. As such, they are not replaced unless and until they deploy. The subject inflators are hermetically sealed, protecting the interior from elements that may cause propellant degradation.
                    <SU>36</SU>
                    <FTREF/>
                     Nevertheless, ruptures have continued to occur despite manufacturers' assertions that narrower recalls have addressed the safety defect. NHTSA's investigation and analysis of the ruptures supports its preliminary determination that all subject inflators are at risk of rupturing and, therefore, contain a defect.
                </P>
                <FTNT>
                    <P>
                        <SU>36</SU>
                         
                        <E T="03">See</E>
                         USCAR Inflator Technical Requirements and Validation at ¶ 3.2.11 (SAE Int'l, 2023).
                    </P>
                </FTNT>
                <P>During its investigation, NHTSA obtained evidence of issues in the friction welding process of the subject inflators that resulted in either over-pressurization or weld failure when the inflators were commanded to deploy. This propensity for over-pressurization or weld failure, based on one or more variables, can cause and has caused repeated ruptures of the subject inflators. All seven known field ruptures in vehicles in the United States, along with at least twenty-three lot acceptance testing ruptures, were caused by over-pressurization or weld failure. Thus, the evidence demonstrates that the same friction welding process used to manufacture all of the subject inflators creates a risk of rupture. Stated more plainly, any of the subject inflators is subject to over-pressurization or weld failure leading to rupture when commanded to deploy. There is no evidence-based means to predict which specific subject inflators will rupture when commanded to deploy. Limited-scope recalls initiated in response to some of the ruptures were reactionary and narrowly focused and did not proactively address the propensity of the larger population of subject inflators to rupture. As a result, ruptures continued to occur.</P>
                <P>The ruptures that have already occurred in vehicles have demonstrated the unpredictable nature of the defect. As detailed below, these ruptures have involved inflators manufactured at different times and in different manufacturing facilities, both single-stage and dual-stage air bag inflators, driver-side and passenger-side inflators, inflators incorporated into air bag modules by different module suppliers, and inflators used in different vehicle manufacturers' vehicles. The inflators that ruptured due to over-pressurization or weld failure in lot acceptance testing likewise had been manufactured at different times in different manufacturing facilities, included both single-stage and dual-stage air bag inflators, driver-side and passenger-side inflators, and were intended to be sold to different air bag module suppliers. The critical element that the subject inflators have in common is the friction welding process—significant evidence indicates that this process has led to ruptures caused by over-pressurization and weld failure.</P>
                <HD SOURCE="HD3">3. The Inflators Have Ruptured in the Field Seven Times</HD>
                <P>The defect in the subject inflators has manifested in seven confirmed ruptures in vehicles in the United States, injuring at least seven people and killing another.</P>
                <HD SOURCE="HD3">First Field Rupture—January 2009, Ohio</HD>
                <P>
                    The first known field rupture of a subject inflator in the United States occurred on January 29, 2009 in Ohio. The driver of a MY 2002 Chrysler Town &amp; Country was turning into a driveway and collided with another vehicle. The crash triggered air bag deployment, and the driver-side, dual-stage air bag inflator—manufactured in ARC's Knoxville, Tennessee plant—ruptured, sending pieces of metal through the air bag cushion and into the occupant compartment. The driver sustained severe injuries to the face, neck, shoulder, and jaw, causing permanent muscle and nerve damage.
                    <SU>37</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>37</SU>
                         
                        <E T="03">See</E>
                         VOQ dated Dec. 20, 2014.
                    </P>
                </FTNT>
                <P>
                    During an inspection of the vehicle, ARC took photographs of the pieces of the ruptured inflator, including the center support. When the inflator in the MY 2002 Chrysler Town &amp; Country ruptured, the center support elongated, split into two pieces, and ejected from 
                    <PRTPAGE P="63479"/>
                    the inflator housing.
                    <SU>38</SU>
                    <FTREF/>
                     These characteristics indicate that a rupture was caused by over-pressurization of the inflator.
                    <SU>39</SU>
                    <FTREF/>
                     The photos of the upper portion of the center support show a blockage in the exit orifice.
                    <SU>40</SU>
                    <FTREF/>
                     NHTSA and ARC agree that because this blockage prevented the gas from escaping through the exit orifice, the pressure inside the inflator built and exceeded the inflator's strength limit and, ultimately, the inflator over-pressurized and broke apart (
                    <E T="03">i.e.,</E>
                     ruptured). ARC posited that the blockage was caused by a piece of the flash-dam pin, a tool that is inserted through the exit orifice during the friction welding process in an attempt to prevent weld flash from blocking the gas flow. The flash-dam pin is normally removed after completion of the weld, but based on visual inspection of the photographs, ARC suggested that a piece of this pin broke off during the manufacturing process and, during deployment, blocked the inflator's exit orifice.
                    <SU>41</SU>
                    <FTREF/>
                     No metallurgical testing was done to determine the composition of the blockage material.
                </P>
                <FTNT>
                    <P>
                        <SU>38</SU>
                         
                        <E T="03">See</E>
                         Photos of air bag parts from MY 2002 Chrysler Town &amp; Country Rupture at pp. 6-9.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>39</SU>
                         
                        <E T="03">See</E>
                         ARC Presentation dated Mar. 1, 2016 on MY 2004 Kia Optima Rupture at pp. 5, 22; ARC Presentation dated Aug. 25, 2017 on SGO 2016-01/2017-01 Report 39 at pp. 6, 11, 37; ARC Response to Request 1 of NHTSA Aug. 25, 2015 IR Letter at p. 72.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>40</SU>
                         
                        <E T="03">See</E>
                         Photos of air bag parts from MY 2002 Chrysler Town &amp; Country Rupture at pp. 6-9.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>41</SU>
                         
                        <E T="03">See</E>
                         Written Response of ARC Automotive, Inc. to the September 5, 2023, Initial Decision Docket No. NHTSA-2023-0038 at p. 32, 
                        <E T="03">https://www.regulations.gov/comment/NHTSA-2023-0038-0027.</E>
                    </P>
                </FTNT>
                <P>
                    The vehicle manufacturer, FCA,
                    <SU>42</SU>
                    <FTREF/>
                     has not advanced any contrasting potential explanation for this field rupture.
                </P>
                <FTNT>
                    <P>
                        <SU>42</SU>
                         Then known as Chrysler.
                    </P>
                </FTNT>
                <HD SOURCE="HD3">Second Field Rupture—April 2014, New Mexico</HD>
                <P>
                    The second known field rupture of a subject inflator occurred on April 8, 2014 in New Mexico. The driver of a MY 2004 Kia Optima collided with a roadside barrier, triggering air bag deployment. The driver-side, single stage air bag inflator—manufactured in ARC's Knoxville, Tennessee plant—ruptured, and fragments were propelled through the air bag cushion and into the occupant compartment. At the hospital, a piece of the shrapnel was removed from the driver's neck.
                    <SU>43</SU>
                    <FTREF/>
                     The driver was also treated for head trauma, a jaw fracture, and lacerations to the lip, neck, and cheek.
                    <SU>44</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>43</SU>
                         
                        <E T="03">See</E>
                         Medical Discharge Summaries, Report ID ****8352 at p. 3.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>44</SU>
                         
                        <E T="03">See id.</E>
                    </P>
                </FTNT>
                <P>
                    ARC conducted a visual, on-site inspection of the vehicle and inflator parts and took photographs of the vehicle and inflator pieces. As with the MY 2002 Chrysler Town &amp; Country rupture, the center support of the inflator elongated, broke into two pieces, and ejected from the inflator housing.
                    <SU>45</SU>
                    <FTREF/>
                     ARC concluded that the inflator ruptured due to over-pressurization,
                    <SU>46</SU>
                    <FTREF/>
                     a conclusion with which NHTSA agrees. ARC's analysis identified exit orifice blockage as the most likely cause of the over-pressurization and rupture.
                    <SU>47</SU>
                    <FTREF/>
                     The photographs of the center support taken after the rupture occurred do not show that a blockage remained in the exit orifice.
                    <SU>48</SU>
                    <FTREF/>
                     ARC surmised that an internal blockage of the exit orifice was unlikely based on this observation and three additional indicators: (1) during manufacturing, the inflator had been filled with the stored, internal gas through the exit orifice, (2) the lot acceptance test data for the associated lot of inflators was compliant, and (3) the exit orifice diameter was an acceptable size.
                    <SU>49</SU>
                    <FTREF/>
                     ARC hypothesized, instead, that the over-pressurization was caused by an 
                    <E T="03">external</E>
                     blockage of the exit orifice and conducted tests to mimic this condition.
                    <SU>50</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>45</SU>
                         
                        <E T="03">See</E>
                         ARC Presentation dated Mar. 1, 2016 on MY 2004 Kia Optima Rupture at pp. 5, 22.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>46</SU>
                         
                        <E T="03">See id.</E>
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>47</SU>
                         
                        <E T="03">See id.</E>
                         at pp. 5, 7, 32.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>48</SU>
                         
                        <E T="03">See id.</E>
                         at pp. 8-9.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>49</SU>
                         
                        <E T="03">See id.</E>
                         at p. 68.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>50</SU>
                         
                        <E T="03">See id.</E>
                         at pp. 70-71, 74.
                    </P>
                </FTNT>
                <P>
                    The photos of the center support in this instance do not show exit orifice blockage; however, the blockage could have been knocked out of the exit orifice when the inflator ruptured, as likely happened in several of the lot acceptance test ruptures believed to have been caused by internal exit orifice blockage.
                    <SU>51</SU>
                    <FTREF/>
                     Debris found inside the air bag cushion after this rupture was of a sufficient size to block the exit orifice.
                    <SU>52</SU>
                    <FTREF/>
                     Therefore, the evidence does not undermine internal blockage as the underlying reason for the over-pressurization in this incident. The three additional indicators listed above and cited by ARC are present for each of the U.S. field ruptures and do not, separately or combined, refute internal blockage of the exit orifice as the cause of over-pressurization.
                </P>
                <FTNT>
                    <P>
                        <SU>51</SU>
                         
                        <E T="03">See</E>
                         ARC Presentation dated Apr. 1, 2017 on SGO 2016-01/2017-01 Report 80 at pp. 8-11; ARC Presentation dated Nov. 10, 2017 on SGO 2016-01/2017-01 Report 120 at p. 7; ARC Presentation dated Apr. 5, 2017 on SGO 2016-01/2017-01 Report 130 at pp. 8-11; ARC Presentation dated Nov. 8, 2017 on SGO 2016-01/2017-01 Report 178 at pp. 13-14.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>52</SU>
                         
                        <E T="03">See</E>
                         Photo 25 from inspection of MY 2004 Kia Optima rupture; Photo 27 from inspection of MY 2004 Kia Optima rupture; Photo 29 from inspection of MY 2004 Kia Optima rupture; Photo 31 from inspection of MY 2004 Kia Optima rupture; Photo 33 from inspection of MY 2004 Kia Optima rupture; Photo 34 from inspection of MY 2004 Kia Optima rupture.
                    </P>
                </FTNT>
                <P>In comments, Kia disputed that the rupture may have been caused by weld slag blocking the inflator orifice and noted a number of observations. However, in attempting to explain the rupture, Kia could only conclude that it was “an isolated case of unknown cause.”</P>
                <HD SOURCE="HD3">Third Field Rupture—September 2017, Pennsylvania</HD>
                <P>
                    The third known field rupture occurred on September 22, 2017 in Pennsylvania. The driver of a MY 2011 Chevrolet Malibu rear-ended another vehicle, triggering air bag deployment. The driver-side, dual stage air bag inflator—manufactured in ARC's Reynosa, Mexico plant 
                    <SU>53</SU>
                    <FTREF/>
                    —ruptured. Pieces of the inflator shot through the air bag cushion and into the occupant compartment. The shrapnel caused multiple fractures to the driver's face, nose, and jaw as well as other trauma, lacerations, and nerve damage to the face.
                    <SU>54</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>53</SU>
                         In the September 5, 2023 Initial Decision, the description of this field rupture incorrectly stated that the vehicle was a MY 2010 Chevrolet Malibu and that the inflator had been manufactured in Xi'an China.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>54</SU>
                         
                        <E T="03">See</E>
                         Complaint filed in lawsuit arising from the crash on Sept. 22, 2017 at pp. 11-12.
                    </P>
                </FTNT>
                <P>
                    General Motors (GM) took photographs of the vehicle and inflator during an on-site inspection. A visual inspection of photos of the inflator shows that the center support did not elongate, split in two, or eject from the inflator.
                    <SU>55</SU>
                    <FTREF/>
                     These characteristics are unique to this field rupture. Based on observations made during physical inspections on December 13, 2018 and January 22, 2019, GM noted the lack of center support elongation as an indication that the exit orifice was not blocked in this rupture.
                    <SU>56</SU>
                    <FTREF/>
                     Neither GM nor ARC nor NHTSA were able to conduct destructive testing on the inflator, so all conclusions and hypotheses were based on visual inspection of the photographs.
                </P>
                <FTNT>
                    <P>
                        <SU>55</SU>
                         
                        <E T="03">See</E>
                         Photos from inspection of MY 2011 Chevrolet Malibu rupture at p. 65; GM Presentation dated Jan. 29, 2019 on MY 2011 Chevrolet Malibu rupture at pp. 4-6.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>56</SU>
                         
                        <E T="03">See</E>
                         GM Presentation dated Jan. 29, 2019 on MY 2011 Chevrolet Malibu rupture at pp. 1, 3.
                    </P>
                </FTNT>
                <P>
                    Based on information available to it, ARC proffered a potential explanation that partially attributed the rupture to issues with Operation 50 of the inflator manufacturing process.
                    <SU>57</SU>
                    <FTREF/>
                     Similarly, GM 
                    <PRTPAGE P="63480"/>
                    noted that the inflator ruptured specifically at the Operation 50 weld, along with another weld.
                    <SU>58</SU>
                    <FTREF/>
                     For driver-side subject inflators, Operation 50 is the point in the manufacturing process at which two friction welds occur: The center support is friction welded to the inside of the lower half of the inflator housing, and, at the same time, the lower and upper halves of the inflator housing are friction welded together.
                    <SU>59</SU>
                    <FTREF/>
                     In their analyses of this field rupture, ARC and GM identified issues with this particular friction weld and posited those issues as potential causes of the rupture. These descriptions are repeated in ARC's analyses of certain ruptures that occurred during lot acceptance testing where deficiencies in this same friction weld were identified as having contributed to each failure.
                    <SU>60</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>57</SU>
                         
                        <E T="03">See</E>
                         ARC Presentation dated Mar. 21, 2019 on MY 2011 Chevrolet Malibu rupture at p. 4.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>58</SU>
                         
                        <E T="03">See</E>
                         GM Presentation dated Jan. 29, 2019 on MY 2011 Chevrolet Malibu rupture at p. 3.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>59</SU>
                         
                        <E T="03">See</E>
                         ARC Presentation on CADH Inflator Design at slide 12.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>60</SU>
                         
                        <E T="03">See</E>
                         ARC Presentation dated Oct. 17, 2016 on SGO 2016-01/2017-01 Report 3 at pp. 14-16; ARC Report dated Nov. 4, 2016 under SGO 2016-01/2017-01 Report 5 at p. 2; ARC Report dated Nov. 4, 2016 under SGO 2016-01/2017-01 Report 5 at p. 2; ARC Presentation dated Nov. 7, 2016 on SGO 2016-01/2017-01 Report 12 at slides 39-40; ARC Report dated Dec. 12, 2016 under SGO 2016-01/2017-01 Report 13; ARC Report dated Dec. 12, 2016 under SGO 2016-01/2017-01 Report 18; ARC Presentation dated Feb. 8, 2017 on A9/ZB Model Inflators at pp. 2-3; ARC Presentation dated May 14, 2017 on SGO 2016-01/2017-01 Report 20 at slides 27-30; ARC Report dated Dec. 14, 2016 under SGO 2016-01/2017-01 Report 22 at p. 2.
                    </P>
                </FTNT>
                <P>
                    While NHTSA acknowledges that characteristics of this field rupture differ from those seen in the other U.S. field ruptures, they do not undermine the agency's defect determination. These characteristics are not anomalous or isolated; they also appear in several lot acceptance test ruptures. After studying each such rupture, ARC attributed all of these ruptures partially to friction weld failures.
                    <SU>61</SU>
                    <FTREF/>
                     Moreover, manufacturers attributed other field and lot acceptance test ruptures to additional issues related to the friction welding process, including excessive weld flash—created by friction welding—that blocked the exit orifice, and a broken piece of the flash-dam pin—a tool used to try to prevent weld flash blockage—that blocked the exit orifice. In fact, the extent to which the MY 2011 Chevrolet Malibu rupture differs from other field ruptures serves as evidence that there are variations in the friction welding process, intentional or unintentional, that can lead and have led to ruptures.
                </P>
                <FTNT>
                    <P>
                        <SU>61</SU>
                         
                        <E T="03">See id.</E>
                    </P>
                </FTNT>
                <P>Appearing to recognize these variations, several commenters suggested that more testing and analysis of the variables in the subject inflators' design and manufacturing process is needed to support NHTSA's initial decision. However, in the many years since the first ruptures occurred and the investigation opened, the agency and the manufacturers have conducted extensive analyses. To the extent some commenters point to a lack of confirmed root cause for every incident, the agency notes that a root cause determination is not required to determine that a defect exists, as discussed further below in section II.A.6. The agency also does not believe that additional analysis is likely to shed meaningful light on issues that remain unsettled at this point. In light of the severe safety risk, the Safety Act warrants a recall based on the already clear evidence of a defect.</P>
                <HD SOURCE="HD3">Fourth Field Rupture—August 2021, Michigan</HD>
                <P>
                    The fourth known field rupture occurred on August 15, 2021. In Michigan, the driver of a MY 2015 Chevrolet Traverse vehicle, returning from a family outing with her children,
                    <SU>62</SU>
                    <FTREF/>
                     was turning onto a highway and was struck by another vehicle. The air bags deployed, and the driver-side, dual stage air bag inflator—manufactured in ARC's Reynosa, Mexico plant—ruptured, sending fragments of metal through the air bag cushion and into the occupant compartment. The pieces of the center support struck the driver in the neck, and the driver died from the injury.
                </P>
                <FTNT>
                    <P>
                        <SU>62</SU>
                         Public Meeting Transcript and Addenda at pp. 73-74, Docket No. NHTSA-2023-0038, 
                        <E T="03">https://www.regulations.gov/document/NHTSA-2023-0038-0003.</E>
                    </P>
                </FTNT>
                <P>
                    One of the driver's children traveled from Michigan to Washington, DC to speak at the public meeting on October 5, 2023 in support of NHTSA's initial determination that the subject inflators are defective and should be recalled. During the meeting, he described in detail his presence at the crash scene and how the air bag, rather than protecting his mother from injury, exploded, sent metal shrapnel into her face and neck, and ultimately killed her.
                    <SU>63</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>63</SU>
                         
                        <E T="03">Id.</E>
                    </P>
                </FTNT>
                <P>
                    Photos taken by Michigan State Police personnel after the crash show that the center support elongated, split in two, and ejected from the inflator,
                    <SU>64</SU>
                    <FTREF/>
                     demonstrating that over-pressurization caused the rupture. The Michigan State Police also performed X-rays of the inflator pieces and provided the images to GM.
                    <SU>65</SU>
                    <FTREF/>
                     The X-rays do not show any obstruction in the exit orifice.
                    <SU>66</SU>
                    <FTREF/>
                     NHTSA does not believe the X-ray images negate the possibility of exit orifice blockage. The force of the rupture could have knocked any blockage material loose, as the evidence suggests happened in lot acceptance test ruptures. 
                    <SU>67</SU>
                    <FTREF/>
                     Moreover, an X-ray image is not always detailed enough to identify witness marks caused by debris in the exit orifice.
                </P>
                <FTNT>
                    <P>
                        <SU>64</SU>
                         
                        <E T="03">See</E>
                         Photos from inspection of MY 2015 Chevrolet Traverse rupture in Michigan at pp. 188-229.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>65</SU>
                         
                        <E T="03">See</E>
                         GM Presentation dated Oct. 6, 2021 on MY 2015 Chevrolet Traverse rupture in Michigan at p. 10.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>66</SU>
                         
                        <E T="03">See id.</E>
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>67</SU>
                         
                        <E T="03">See</E>
                         ARC Presentation dated Apr. 1, 2017 on SGO 2016-01/2017-01 Report 80 at pp. 8-11; ARC Presentation dated Nov. 10, 2017 on SGO 2016-01/2017-01 Report 120 at p. 7; ARC Presentation dated Apr. 5, 2017 on SGO 2016-01/2017-01 Report 130 at pp. 8-11; ARC Presentation dated Nov. 8, 2017 on SGO 2016-01/2017-01 Report 178 at pp. 13-14.
                    </P>
                </FTNT>
                <P>
                    GM noted that the X-ray images for this field rupture did not show material in the exit orifice and that CT scans of inflators retrieved from the same lot did not show exit orifice blockage.
                    <SU>68</SU>
                    <FTREF/>
                     As explained above, X-ray images cannot rule out exit orifice blockage as the cause of over-pressurization, and, furthermore, lot-based comparisons are not broad enough to guarantee that the risk is contained. GM studied this rupture in tandem with the subsequent fifth field rupture (discussed in more detail below) and a lot acceptance test rupture.
                    <SU>69</SU>
                    <FTREF/>
                     The remainder of GM's analysis related to propellant was not specifically applicable to this field rupture.
                    <SU>70</SU>
                    <FTREF/>
                     ARC likewise has not offered any potential explanations for this fatal field rupture incident, though it is undisputed that over-pressurization ultimately caused the rupture.
                </P>
                <FTNT>
                    <P>
                        <SU>68</SU>
                         
                        <E T="03">See</E>
                         GM Presentation dated Jun. 15, 2022 on DAB ARC Inflator Ruptures at p. 2.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>69</SU>
                         
                        <E T="03">See id.</E>
                         at p. 1.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>70</SU>
                         GM enlisted the help of an independent research firm to study propellant-related issues more broadly. The group studied 329 driver-side subject inflators manufactured between 2013 and 2021. While the study identified “[m]any areas of manufacturing variability,” it concluded that “moisture migration into the propellant,” which is the cause of propellant degradation, “is not a concern in this inflators design.” 
                        <E T="03">See</E>
                         Northrop Grumman Presentation dated May 5, 2023 on GM ARC Inflator Investigation at p. 48. GM did not identify a specific explanation for the inflator ruptures but proposed that too much propellant, low propellant density, and “possible other unknown factors” may be considered as contributors. 
                        <E T="03">See</E>
                         GM Presentation dated Jun. 15, 2022 on DAB ARC Inflator Ruptures at p. 1.
                    </P>
                </FTNT>
                <HD SOURCE="HD3">Fifth Field Rupture—October 2021, Kentucky</HD>
                <P>
                    The fifth known field rupture occurred on October 20, 2021. In Kentucky, the driver of a MY 2015 Chevrolet Traverse vehicle collided with another vehicle at an intersection, which triggered the air bags to deploy. 
                    <PRTPAGE P="63481"/>
                    The driver-side, dual stage air bag inflator—manufactured in ARC's Reynosa, Mexico plant—ruptured, and fragments of the metal inflator were projected through the air bag cushion and into the occupant compartment. The driver sustained injuries to the face.
                </P>
                <P>
                    Photographs were taken of the vehicle as well as the ruptured inflator pieces. The photos show that the center support elongated, split in two, and ejected from the inflator,
                    <SU>71</SU>
                    <FTREF/>
                     demonstrating that over-pressurization caused the rupture. The upper portion of the broken center support shot through the air bag cushion and into the driver-seat head rest.
                    <SU>72</SU>
                    <FTREF/>
                     The photos of this piece of the center support show material blocking the exit orifice.
                    <SU>73</SU>
                    <FTREF/>
                     GM suggests the material may be fabric from the head rest,
                    <SU>74</SU>
                    <FTREF/>
                     however, a determination of the blockage material has not been confirmed as the manufacturers were not able to perform an analysis of the material to identify its makeup.
                </P>
                <FTNT>
                    <P>
                        <SU>71</SU>
                         
                        <E T="03">See</E>
                         GM Presentation dated Apr. 6, 2022 on MY 2015 Chevrolet Traverse rupture in Kentucky at p. 3.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>72</SU>
                         
                        <E T="03">See id.</E>
                         at p. 4.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>73</SU>
                         
                        <E T="03">See id.</E>
                         at p. 3.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>74</SU>
                         
                        <E T="03">See id.</E>
                    </P>
                </FTNT>
                <P>
                    GM assessed this field rupture in tandem with the previous field rupture and a lot acceptance test rupture, as explained above in discussing the fourth rupture (2021 Michigan). As GM stated in that analysis, no parts from the same lot as the inflator in this field rupture were available for analysis,
                    <SU>75</SU>
                    <FTREF/>
                     so the conclusions in its report are not particularly relevant. GM did not perform a separate analysis for this field rupture. Similarly, ARC has not provided a potential explanation for this rupture.
                </P>
                <FTNT>
                    <P>
                        <SU>75</SU>
                         
                        <E T="03">See</E>
                         GM Presentation dated Jun. 15, 2022 on DAB ARC Inflator Ruptures at p. 2.
                    </P>
                </FTNT>
                <HD SOURCE="HD3">Sixth Field Rupture—December 2021, California</HD>
                <P>
                    The sixth known field rupture occurred on December 18, 2021 in California. The driver of a MY 2016 Audi A3 e-Tron collided with another vehicle. The air bags deployed, and the passenger-side, dual stage inflator—manufactured in ARC's Reynosa, Mexico plant—ruptured, with some of the fragments projecting through the air bag cushion and into the occupant compartment. The passenger suffered serious injuries to the face and ear.
                    <SU>76</SU>
                    <FTREF/>
                     The pieces of the inflator also struck the driver, causing lacerations to the right hand and right shin.
                    <SU>77</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>76</SU>
                         
                        <E T="03">See</E>
                         Complaint filed in lawsuit arising from the crash on Dec. 18, 2021 at p. 2.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>77</SU>
                         
                        <E T="03">See</E>
                         State of California Crash Report dated Dec. 18, 2021 at p. 3.
                    </P>
                </FTNT>
                <P>
                    Photos from the vehicle inspection indicate that the center support split in two and ejected from the inflator,
                    <SU>78</SU>
                    <FTREF/>
                     demonstrating that over-pressurization caused the rupture. The upper portion of the center support ultimately ejected through the windshield and the lower portion became lodged in the instrument panel.
                    <SU>79</SU>
                    <FTREF/>
                     The upper portion of the center support was never recovered and, therefore, never analyzed for blockage. Neither ARC nor Volkswagen has offered potential explanations for this rupture.
                </P>
                <FTNT>
                    <P>
                        <SU>78</SU>
                         
                        <E T="03">See</E>
                         Photos from inspection of MY 2016 Audi A3 e-Tron rupture.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>79</SU>
                         
                        <E T="03">See id.</E>
                    </P>
                </FTNT>
                <HD SOURCE="HD3">Seventh Field Rupture—March 2023, Michigan</HD>
                <P>
                    The seventh, and most recent, known field rupture occurred on March 22, 2023 in Michigan. The driver of a MY 2017 Chevrolet Traverse vehicle collided with a tree, causing the air bags to deploy. The driver-side, dual stage inflator—manufactured in ARC's Reynosa, Mexico plant—ruptured, sending fragments through the air bag cushion and into the occupant compartment. The driver suffered injuries to the face, teeth, and neck. A child in the back seat also suffered lacerations to the face, potentially caused by shrapnel from the inflator rupture or other debris from the crash. The upper portion of the center support struck the driver in the neck and had to be surgically removed from the driver's airway.
                    <SU>80</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>80</SU>
                         
                        <E T="03">See</E>
                         Email dated Apr. 5, 2023 to NHTSA from Hurley Medical Center; Photos attached to email dated Apr. 5, 2023 to NHTSA from Hurley Medical Center.
                    </P>
                </FTNT>
                <P>
                    Photos taken of the vehicle and pieces of the inflator show that the center support elongated, split in two, and ejected from the inflator,
                    <SU>81</SU>
                    <FTREF/>
                     once again demonstrating that over-pressurization caused the rupture. Photos of the removed upper center support show that the exit orifice was completely blocked.
                    <SU>82</SU>
                    <FTREF/>
                     No further explanation for this rupture has been advanced by ARC or GM.
                </P>
                <FTNT>
                    <P>
                        <SU>81</SU>
                         
                        <E T="03">See</E>
                         Photo 10 from inspection of MY 2017 Chevrolet Traverse rupture; Photo 35 from inspection of MY 2017 Chevrolet Traverse rupture; Photo 38 from inspection of MY 2017 Chevrolet Traverse rupture; Photo 17 from inspection of MY 2017 Chevrolet Traverse rupture.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>82</SU>
                         
                        <E T="03">See</E>
                         Photos attached to email dated Apr. 5, 2023 to NHTSA from Hurley Medical Center; Photo 38 from inspection of MY 2017 Chevrolet Traverse rupture; Photo 36 from inspection of MY 2017 Chevrolet Traverse rupture; Photo 48 from inspection of MY 2017 Chevrolet Traverse rupture; Photo 45 from inspection of MY 2017 Chevrolet Traverse rupture.
                    </P>
                </FTNT>
                <HD SOURCE="HD3">Foreign Field Ruptures</HD>
                <P>
                    In addition to the seven confirmed field ruptures in the U.S., there are four confirmed ruptures of frontal driver- and passenger-side hybrid toroidal ARC inflators that occurred in other countries. In July of 2016, a driver-side hybrid toroidal ARC inflator manufactured in ARC's Xi'an, China plant ruptured in a MY 2009 Hyundai Elantra in Canada.
                    <SU>83</SU>
                    <FTREF/>
                     The center support split into two pieces and ejected, a piece of which struck and killed the driver.
                    <SU>84</SU>
                    <FTREF/>
                     In October of 2017, a passenger-side hybrid toroidal ARC inflator manufactured in ARC's Knoxville, Tennessee plant ruptured in a MY 2015 Volkswagen Golf in Turkey.
                    <SU>85</SU>
                    <FTREF/>
                     The center support split in two and ejected from the inflator housing, and Volkswagen hypothesized that weld flash blockage of the exit orifice caused the rupture.
                    <SU>86</SU>
                    <FTREF/>
                     Fortunately, there was no passenger in the vehicle, and no one was injured.
                    <SU>87</SU>
                    <FTREF/>
                     In March of 2020, a passenger-side hybrid toroidal ARC inflator manufactured in ARC's Xi'an, China plant ruptured in a 2009 Hyundai Elantra in Saudi Arabia, sending fragments of metal into the occupant compartment.
                    <SU>88</SU>
                    <FTREF/>
                     The driver sustained injuries in the incident.
                    <SU>89</SU>
                    <FTREF/>
                     In October of 2021, a driver-side hybrid toroidal ARC inflator manufactured in ARC's Xi'an, China plant ruptured in a MY 2011 Hyundai Elantra Touring in Saudi Arabia.
                    <SU>90</SU>
                    <FTREF/>
                     The center support broke into two pieces and ejected from the inflator housing.
                    <SU>91</SU>
                    <FTREF/>
                     The driver was seriously injured when a piece of the center support struck the driver's arm and had to be surgically removed.
                    <SU>92</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>83</SU>
                         
                        <E T="03">See</E>
                         Hyundai Report dated Jul. 20, 2016 under SGO 2015-01/2015-02; Hyundai Letter to NHTSA dated Apr. 15, 2020 at p. 2.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>84</SU>
                         
                        <E T="03">See</E>
                         Hyundai Report dated Jul. 20, 2016 under SGO 2015-01/2015-02; Hyundai Letter to NHTSA dated Apr. 15, 2020 at p. 2; Photo 1 from inspection of MY 2009 Hyundai Elantra rupture; Photo 2 from inspection of MY 2009 Hyundai Elantra rupture; Photo 375 from inspection of MY 2009 Hyundai Elantra rupture.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>85</SU>
                         
                        <E T="03">See</E>
                         Key Safety Systems Report dated Dec. 1, 2017 under SGO 2015-01/2015-02.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>86</SU>
                         
                        <E T="03">See</E>
                         Photos from inspection of MY 2015 Volkswagen Golf rupture; Volkswagen Presentation on MY 2015 Volkswagen Golf rupture.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>87</SU>
                         
                        <E T="03">See</E>
                         Key Safety Systems Report dated Dec. 1, 2017 under SGO 2015-01/2015-02.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>88</SU>
                         
                        <E T="03">See</E>
                         Hyundai Letter to NHTSA dated Apr. 15, 2020 at p. 2.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>89</SU>
                         
                        <E T="03">See</E>
                         Hyundai Report dated Mar. 30, 2020 under SGO 2015-01/2015-02.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>90</SU>
                         
                        <E T="03">See</E>
                         Hyundai Report dated Apr. 7, 2023 under SGO 2015-01/2015-02; Hyundai Report dated May 26, 2023 on Canada Safety Recall R0239 ARC Inflator.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>91</SU>
                         
                        <E T="03">See</E>
                         Information package provided by the Saudi Ministry of Commerce and Industry.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>92</SU>
                         
                        <E T="03">See id.</E>
                    </P>
                </FTNT>
                <PRTPAGE P="63482"/>
                <HD SOURCE="HD3">4. A Comparison to Peer Inflators Supports a Defect Determination</HD>
                <P>
                    While the overall incidence of rupture is rare, these failures can result and have resulted in severe injury or death. As such, and considering the evidence of problems in the friction welding process, the subject inflators present a defect. Moreover, the number of field ruptures in the United States described here stands in stark contrast to the near absence of such occurrences from other manufacturers of frontal air bag inflators. In assessing a defect, courts have considered how the number of failures compares to the number seen from other manufacturers particularly in situations where—unlike here—the circumstances of failure do not reveal an obvious defect. 
                    <E T="03">See, e.g., Wheels,</E>
                     518 F.2d at 438 n.84. Such a comparison further bolsters the conclusion that the subject inflators are defective.
                </P>
                <P>
                    As previously discussed in section I, SGOs 2015-01A and 2015-02A require all manufacturers to report alleged inflator field ruptures to NHTSA. Out of all of the field ruptures reflected in reports received as of July 2024,
                    <SU>93</SU>
                    <FTREF/>
                     NHTSA identified only one comparable U.S. field rupture of a non-ARC air bag inflator, which has resulted in three recalls.
                    <SU>94</SU>
                    <FTREF/>
                     The agency recognizes that the predecessor SGOs, 2015-01 and 2015-02 (with similar reporting requirements), were first issued on July 27, 2015. NHTSA believes it likely, however, that if other alleged ruptures had occurred before the SGOs' issuance, the agency would have been made aware of them through various channels. For example, the first Takata inflator ruptures occurred in 2007-2008,
                    <SU>95</SU>
                    <FTREF/>
                     and the first Takata recall was initiated in 2008, so it is likely that, due to the publicity, any inflator ruptures after that time would have been reported to NHTSA through a complaint, which is how NHTSA learned of the subject inflator rupture in the MY 2002 Chrysler Town &amp; Country.
                    <SU>96</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>93</SU>
                         This does not include field ruptures—based on the agency's review of these reports and field incidents—that involved inflators manufactured by Takata, many of which have long been under recall. As one commenter asserted (albeit in the context of discussing how to define the defective population) it is difficult to make “direct rate comparisons” between the inflators here and those in the Takata recalls, and the Takata recalls “have limited comparative value” given, among other things, the apparent failure mechanisms and the number of reported deaths and injuries associated with Takata air bag inflators. Comments of Jay Logel at p. 7 (Dec. 18, 2023).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>94</SU>
                         NHTSA Recall Nos. 20V-681, 21V-766, and 21V-800.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>95</SU>
                         Approximately 67 million non-desiccated Takata PSAN air bag inflators, across nineteen vehicle manufacturers, are under recall because they may rupture when deployed, causing serious injury or even death. Certain other types of Takata inflators are also under recall. For more information about the Takata air bag inflator recalls, see 
                        <E T="03">Takata Recall Spotlight</E>
                         (NHTSA), 
                        <E T="03">https://www.nhtsa.gov/vehicle-safety/takata-recall-spotlight.</E>
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>96</SU>
                         In addition, since 2002, manufacturers have been required under NHTSA's early warning reporting regulations to report on incidents involving injury or death. 
                        <E T="03">See</E>
                         49 CFR part 579, subpart C.
                    </P>
                </FTNT>
                <P>
                    A collection of all SGO reports involving confirmed ruptures of frontal driver and passenger air bag inflators thus yielded a total of eighteen potentially relevant reports involving non-ARC inflators. Of these eighteen, ten of the reported ruptures occurred outside of the United States. Relative to the U.S. market, the agency does not have the requisite depth of information (
                    <E T="03">e.g.,</E>
                     the total inflator population manufactured for each additional relevant foreign market) to enable an effective peer comparison that would encompass inflators manufactured for the various foreign markets. In addition, the considerations relevant to determining whether a defect exists under U.S. law may not be the same in other countries. The foreign ruptures are, therefore, not included in a comparison with seven U.S. subject inflator field ruptures.
                    <SU>97</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>97</SU>
                         To the extent any of the foreign field ruptures evidence a pattern, the agency is taking a closer look to ensure such trends do not implicate vehicles or equipment in the U.S.
                    </P>
                </FTNT>
                <P>
                    Of the remaining eight ruptures in the collection of reports, six inflators appear to be substandard or imitation products not designed or manufactured to meet U.S. safety standards or based on the same industry standards as legitimate inflators. For this reason, they should not be used as peer comparators. Of the remaining two ruptures, one involved reported damage—scratching—on the inflator housing that appeared to have been caused by a tool and not by deployment or rupture. Further, while the reporting inflator manufacturer confirmed a rupture, the reporting vehicle manufacturer did not.
                    <SU>98</SU>
                    <FTREF/>
                     Given that none of the seven ruptures involving the subject inflators contained similar evidence, it is inappropriate to use this event in a comparison.
                </P>
                <FTNT>
                    <P>
                        <SU>98</SU>
                         
                        <E T="03">Compare</E>
                         Air Bag Inflator Rupture Incident Report (Initial &amp; Final), Autoliv (Dec. 2, 2016) (confirming rupture but noting that “scratching” on areas of the inflator are “not consistent with Autoliv's quality requirements and the inflator exhibits damage/scratches inconsistent with normal deployment or a rupture”) 
                        <E T="03">with</E>
                         Air Bag Inflator Rupture Incident Report (Final), Nissan (Dec. 20, 2016) (“There is damage on the outside of the housing which appears to be caused by an external tool, as evidenced by the multiple witness marks surrounding the hole in the inflator. Nissan does not believe that a rupture occurred in this incident.”).
                    </P>
                </FTNT>
                <P>Appropriately filtering the list of confirmed ruptures of frontal driver- and passenger-side air bag inflators to include true peer incidents, there is only a single field rupture from all other inflator manufacturers to compare to the seven subject inflator field ruptures. As noted above, that rupture already resulted in three recalls, and the scope of vehicles under these recalls is broader than just a particular lot. NHTSA is not aware of further ruptures of that type of inflator, which is distinguishable from the repeated ruptures of the subject inflators. After each lot recall of subject inflators, another inflator outside the scope of the recall eventually ruptured in a vehicle, supporting the need for a more comprehensive recall to address the full defective population.</P>
                <HD SOURCE="HD3">5. ARC's Addition of an Automated Borescope Examination Process Recognizes and Mitigates the Risk of a Field Rupture Due to Exit Orifice Blockage</HD>
                <P>
                    In August of 2017, ARC began adding an automated borescope to the manufacturing process.
                    <SU>99</SU>
                    <FTREF/>
                     After the last friction weld is complete, the borescope inspects the inside of the center support to detect any debris, including weld flash.
                    <SU>100</SU>
                    <FTREF/>
                     By June of 2018, ARC had fully implemented this process by installing these automated borescopes on all assembly lines used to manufacture the subject inflators. ARC rejects any inflator for which the borescope detects material or debris in excess of the specified parameters,
                    <SU>101</SU>
                    <FTREF/>
                     and, from the first borescope installation to March 2023, ARC rejected 195,166 inflators based on the borescope's inspection.
                    <SU>102</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>99</SU>
                         
                        <E T="03">See</E>
                         ARC Presentation dated Oct. 2017 on Automated Borescope.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>100</SU>
                         
                        <E T="03">See id.</E>
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>101</SU>
                         
                        <E T="03">See id.</E>
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>102</SU>
                         
                        <E T="03">See</E>
                         ARC Response to Request 8 of NHTSA May 31, 2023 Special Order.
                    </P>
                </FTNT>
                <P>The automated borescope examination process, which detects excessive weld flash or other debris in the inflator center support, recognizes and mitigates the risk of a field rupture due to exit orifice blockage. The agency is unaware of a field rupture of a frontal, driver- or passenger-side hybrid toroidal inflator manufactured using the borescope examination process. Thus, the subject inflators subject to this initial determination are the inflators manufactured before the full implementation of this process change.</P>
                <P>
                    The borescope process provides additional evidence of the likelihood that problematic levels of debris are present in the subject inflator population. Inflators built after the 
                    <PRTPAGE P="63483"/>
                    borescope process was introduced continued to otherwise undergo the same friction welding process as before the borescope inspection began. This means that the rejection rates from the borescope inspections provide insight into the extent of debris present in the subject inflators, which were produced under similar manufacturing procedures. Before implementation of the borescope process, there was no analogous mechanism in place for detecting—and removing from the manufacturing line—inflators with excessive and dangerous levels of debris.
                </P>
                <P>
                    Moreover, ARC's representations during this investigation suggest that the number of inflators with excessive debris before 2017 was potentially even higher than the extent of debris present in inflators manufactured after borescope implementation. By 2017, ARC claims that it had already taken numerous other steps to update the manufacturing process for the inflators, such as upgrading the welding equipment on several production lines and refining welding tolerances in response to field and testing ruptures.
                    <SU>103</SU>
                    <FTREF/>
                     In this investigation, ARC has claimed that the manufacturing procedures and equipment in place by 2017 were improvements on the procedures and equipment in place in the preceding years of inflator production. If so, the rate of unacceptable inflators due to debris as revealed by the borescope inspections likely would have been even higher for inflators built during the years in which the manufacturing processes were less stringent. At the very least, the nearly 200,000 inflators rejected between the start of the borescope implementation process and March 2023 corroborate the other evidence from analyses of the field ruptures and lot acceptance testing ruptures that suggests a large number of inflators in the subject population contain unacceptable levels of debris, posing a risk of rupture.
                </P>
                <FTNT>
                    <P>
                        <SU>103</SU>
                         
                        <E T="03">See, e.g.,</E>
                         ARC Working Group Meeting Minutes dated Dec. 5, 2017.
                    </P>
                </FTNT>
                <HD SOURCE="HD3">6. The Field and LAT Ruptures Show a Defect Common to All of the Subject Inflators</HD>
                <P>The evidence demonstrates that the friction welding process is responsible for debris and weld insufficiencies, which have led to over-pressurization and weld failures, causing ruptures. The seven confirmed ruptures of the subject inflators in vehicles in the United States each presented evidence of over-pressurization or weld insufficiency as a likely cause of the rupture. In addition, at least twenty-three of the reported lot acceptance test ruptures share over-pressurization or weld insufficiency commonalities with the seven field ruptures. These instances of over-pressurization and weld insufficiency are linked to the friction welding process.</P>
                <P>
                    As described in section II.A.3, ARC and GM identified problems with one of the friction welds in their analyses of the rupture of the MY 2011 Chevrolet Malibu inflator, attributing the rupture as most likely caused by a failure of the friction weld.
                    <SU>104</SU>
                    <FTREF/>
                     ARC reiterated the cause of the rupture as a “welding issue” in its response to the agency's September 2023 initial decision.
                    <SU>105</SU>
                    <FTREF/>
                     In six of the subject inflator ruptures that occurred during lot acceptance tests, ARC identified similar issues related to the same friction weld, again noting that friction weld failure as a potential causes of the ruptures.
                    <SU>106</SU>
                    <FTREF/>
                     In addition, the investigative file contains significant evidence that the friction welding process has led to exit orifice blockage, causing over-pressurization and rupture. Information gathered in three of the U.S. field incidents includes evidence of material in the exit orifice: photos of the upper portion of the center support in the MY 2002 Chrysler Town &amp; Country show an unmistakable blockage in the exit orifice; 
                    <SU>107</SU>
                    <FTREF/>
                     photos of the upper piece of the center support in the MY 2015 Chevrolet Traverse in Kentucky show material blocking the exit orifice; 
                    <SU>108</SU>
                    <FTREF/>
                     and photos of the upper portion of the center support in the MY 2017 Chevrolet Traverse show that the exit orifice was completely blocked.
                    <SU>109</SU>
                    <FTREF/>
                     Exit orifice blockage remains a possible cause based on the evidence for three other incidents—the MY 2004 Kia Optima, the MY 2015 Chevrolet Traverse in Michigan, and the MY 2016 Audi A3 e-Tron. In addition, Volkswagen attributed weld flash blockage leading to over pressurization as a potential cause for the inflator rupture in the MY 2015 Volkswagen Golf in Turkey.
                </P>
                <FTNT>
                    <P>
                        <SU>104</SU>
                         
                        <E T="03">See</E>
                         ARC Presentation dated Mar. 21, 2019 on MY 2011 Chevrolet Malibu rupture at p. 4; GM Presentation dated Jan. 29, 2019 on MY 2011 Chevrolet Malibu rupture at p. 3.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>105</SU>
                         
                        <E T="03">See</E>
                         Written Response of ARC Automotive, Inc. to the September 5, 2023, Initial Decision Docket No. NHTSA-2023-0038 at p. 32, 
                        <E T="03">https://www.regulations.gov/comment/NHTSA-2023-0038-0027</E>
                         at n. 31.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>106</SU>
                         
                        <E T="03">See</E>
                         ARC Presentation dated Oct. 17, 2016 on SGO 2016-01/2017-01 Report 3 at pp. 14-16; ARC Report dated Nov. 4, 2016 under SGO 2016-01/2017-01 Report 5 pdf at p. 2; ARC Report dated Nov. 9, 2016 under SGO 2016-01/2017-01 Report 8 at p. 2; ARC Presentation dated Nov. 7, 2016 on SGO 2016-01/2017-01 Report 12 at slides 39-40; ARC Report dated Dec. 12, 2016 under SGO 2016-01/2017-01 Report 13; ARC Report dated Dec. 12, 2016 under SGO 2016-01/2017-01 Report 18; ARC Presentation dated Feb. 8, 2017 on A9/ZB Model Inflators at pp. 2-3; ARC Presentation dated May 14, 2017 on SGO 2016-01/2017-01 Report 20 at slides 27-30; ARC Report dated Dec. 14, 2016 under SGO 2016-01/2017-01 Report 22 at p. 2.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>107</SU>
                         
                        <E T="03">See id.</E>
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>108</SU>
                         
                        <E T="03">See id.</E>
                         at p. 3.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>109</SU>
                         
                        <E T="03">See</E>
                         Photos attached to email dated Apr. 5, 2023 to NHTSA from Hurley Medical Center; Photo 38 from inspection of MY 2017 Chevrolet Traverse rupture; Photo 36 from inspection of MY 2017 Chevrolet Traverse rupture; Photo 48 from inspection of MY 2017 Chevrolet Traverse rupture; Photo 45 from inspection of MY 2017 Chevrolet Traverse rupture.
                    </P>
                </FTNT>
                <P>
                    Other data support exit orifice blockage as a common factor in these ruptures. In May of 2017, a group of manufacturers involved in the investigation that has been described as the “Collaboration Group” joined together to study the subject inflators. The Collaboration Group analyzed fourteen reports submitted pursuant to SGOs 2016-01 and 2017-01 of passenger-side hybrid toroidal inflator ruptures during lot acceptance test deployments and conducted related testing. The Collaboration Group concluded that all fourteen ruptures were caused by over-pressurization; in all fourteen incidents, the center support elongated, split in two, and ejected from the inflator housing; and, in all fourteen incidents, the upper portion of the center support had material in the exit orifice, witness marks around the exit orifice (indicating debris was forced into the exit orifice upon deployment but was subsequently knocked loose), or other evidence of exit orifice blockage or obstruction.
                    <SU>110</SU>
                    <FTREF/>
                     ARC has acknowledged the exit orifice blockage issue by implementing changes in its Failure Mode and Effects Analysis (FMEA) 
                    <SU>111</SU>
                    <FTREF/>
                     and manufacturing process 
                    <PRTPAGE P="63484"/>
                    to mitigate it.
                    <SU>112</SU>
                    <FTREF/>
                     In fact, ARC implemented the automated borescope to identify excessive weld flash and other debris inside the inflator on all of its toroidal air bag inflator manufacturing lines as a direct response to the Collaboration Group's findings.
                    <SU>113</SU>
                    <FTREF/>
                     The borescope inspection process has identified unacceptable levels of debris in inflators produced on all ARC production lines using friction welding to manufacture hybrid toroidal inflators, which include 20 different production lines across five different ARC manufacturing plants. This extensive range illustrates that problems with excessive debris apply broadly across the subject inflators.
                </P>
                <FTNT>
                    <P>
                        <SU>110</SU>
                         
                        <E T="03">See</E>
                         ARC Presentation dated Feb. 8, 2017 on SGO 2016-01/2017-01 Report 4; ARC Presentation dated Dec. 8, 2016 on Inflator Incidents Update at p. 17; ARC Presentation dated Jan. 10, 2017 on SGO 2016-01/2017-01 Report 39; ARC Presentation dated Mar. 9, 2017 on ZC Anomaly; ARC Presentation dated Apr. 1, 2017 on SGO 2016-01/2017-01 Report 80; ARC Presentation dated Apr. 1, 2017 on SGO 2016-01/2017-01 Report 94; ARC Presentation dated Apr. 5, 2017 on SGO 2016-01/2017-01 Report 95; ARC Presentation dated Nov. 10, 2017 on SGO 2016-01/2017-01 Report 120; ARC Presentation dated Apr. 5, 2017 on SGO 2016-01/2017-01 Report 130; ARC Presentation dated Nov. 10, 2017 on SGO 2016-01/2017-01 Report 158; ARC Presentation dated Nov. 10 2017 on SGO 2016-01/2017-01 Report 176; ARC Presentation dated Nov. 8, 2017 on SGO 2016-01/2017-01 Report 178; ARC Presentation dated Nov. 10 2017 on SGO 2016-01/2017-01 Report 184; ARC Presentation dated Nov. 10 2017 on SGO 2016-01/2017-01 Report 186; ARC Presentation dated Nov. 10 2017 on SGO 2016-01/2017-01 Report 192.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>111</SU>
                         In general, a Failure Mode and Effects Analysis is a qualitative tool associated with the design and manufacturing process that businesses use to identify and analyze potential failures in processes, such as those involving equipment, systems, and personnel. The goal of this analysis is 
                        <PRTPAGE/>
                        to prevent failures, improve processes, and reduce the likelihood of failure causes and effects.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>112</SU>
                         
                        <E T="03">See</E>
                         ARC Presentation dated Apr. 5, 2017 on SGO 2016-01/2017-01 Report 95 at p. 86.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>113</SU>
                         
                        <E T="03">See</E>
                         ARC Working Group 8D Technical Closure Statement at p. 1.
                    </P>
                </FTNT>
                <P>
                    Some commenters suggested that the results of a field recovery program conducted by certain manufacturers during NHTSA's investigation show there is no defect in the subject inflator population. This program was initiated in the early stages of the investigation during the Preliminary Evaluation. During the field recovery program, 918 inflators from a subpopulation of the total subject inflator population were collected from salvage yards and deployed, with none of the inflators rupturing. Given the fact that this testing program was developed after just the first two U.S. field ruptures (the MY 2002 Chrysler Town &amp; Country and the MY 2004 Kia Optima), the inflators tested represent a limited portion of the total subject population. They were selected based on (1) production date, with the vast majority being manufactured between 2001 and 2004, and (2) the vehicles into which the inflators were incorporated, which were Chrysler, Kia, and GM vehicles.
                    <SU>114</SU>
                    <FTREF/>
                     As such, the overall number of inflators recovered and deployed under the field recovery program was low compared to what ultimately became the total number of inflators in the subject population. While there were no ruptures under the field recovery program, ruptures in the field continued: after the program's initiation, there were five additional U.S. ruptures of the subject inflators.
                </P>
                <FTNT>
                    <P>
                        <SU>114</SU>
                         
                        <E T="03">See</E>
                         Field Recovery Program Data Sheet dated May 10, 2018.
                    </P>
                </FTNT>
                <P>
                    The field recovery program confirmed, however, that some inflators in the field contain large amounts of debris. Prior to their deployment, the recovered inflators underwent X-ray imaging and, in some cases, CT scanning to determine whether debris intruded upon the exit orifice opening.
                    <SU>115</SU>
                    <FTREF/>
                     Seven of the recovered inflators were identified as containing such debris, including from weld flash.
                    <SU>116</SU>
                    <FTREF/>
                     All of those inflators deployed normally, which is consistent with the large number of complex variables that may factor into whether debris in the inflator leads to over-pressurization. The existence of this debris around the exit orifice of inflators in the field demonstrates the prevalence of this issue in the subject inflator population.
                </P>
                <FTNT>
                    <P>
                        <SU>115</SU>
                         
                        <E T="03">See</E>
                         ARC Inspection Procedure and Evaluation dated Feb. 28, 2017.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>116</SU>
                         
                        <E T="03">See</E>
                         Field Recovery Program Deployment Data Sheet; ARC Presentation dated Aug. 1, 2017 on Field Recovery Program.
                    </P>
                </FTNT>
                <P>
                    ARC's own failure analysis throughout the investigation has also indicated that, even if the company has been unable to identify the full universe of variables that can lead to a rupture, the commonalities in the failures are sufficient to reveal the nature of the problem—including the failure mode and the aspects of the inflator design and welding process most likely to contribute to it. In 2016, ARC was even able to conduct testing that replicated four ruptures out of 50 deployments.
                    <SU>117</SU>
                    <FTREF/>
                     In doing so, ARC identified five manufacturing variables in the assembly process that, when out of limits, appeared to contribute to the likelihood of a rupture.
                    <SU>118</SU>
                    <FTREF/>
                     ARC's fault trees and failure mode effects analyses similarly isolate the specific steps in the manufacturing process most likely relevant to the ruptures. The existence of factual differences or different variables that led to the ruptures does not establish that the ruptures lacked a common defect.
                </P>
                <FTNT>
                    <P>
                        <SU>117</SU>
                         
                        <E T="03">See</E>
                         ARC Presentation on Design of Experiment #5.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>118</SU>
                         
                        <E T="03">Id.</E>
                         Additional efforts in 2017 to replicate the failure mode in a more precise manner were unsuccessful, further indicating that different variables may combine to contribute to the risk of rupture. 
                        <E T="03">See</E>
                         ARC Working Group Meeting Minutes dated Feb. 13, 2018.
                    </P>
                </FTNT>
                <P>
                    Outside of this investigation, ARC has openly acknowledged the problems with its friction welding process that have led to the defect NHTSA seeks to remedy. For instance, in representations to the United States government outside of this investigation, ARC has acknowledged that the “problematic” characteristics of the subject inflators are not limited to isolated production lots. Specifically, in a patent application filed with the United States Patent and Trademark Office in 2020, ARC requested a patent on an improved air bag inflator design. When explaining the background of existing designs that prompted the need for an improved design, ARC's application represented that “[s]ome existing inflator assemblies utilize a center support structure that requires two simultaneous welds, which is problematic in respect of manufacturing and also increases the potential for weld particles to exit the inflator upon deployment. Existing designs have also been configured to fragment during deployment as a consequence, in the event of excessive pressure increase within the inflator due to some failure or external condition or the like, these existing inflator designs can be potentially hazardous for vehicle occupants.” 
                    <SU>119</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>119</SU>
                         U.S. Pat. App. Pub. No. 2022/0185224 A1 to Rose 
                        <E T="03">et al.,</E>
                         at ¶¶ 0005-06.
                    </P>
                </FTNT>
                <P>
                    The claimed improvements to mitigate these problems with prior inflators focused on the precise aspects of the inflator that are at issue in NHTSA's proceeding. Specifically, ARC intentionally redesigned its inflator in a way that would avoid the friction welding process that caused problems for the subject inflator, such as the step of simultaneously friction welding the top and bottom of the inflator housing to the center support.
                    <SU>120</SU>
                    <FTREF/>
                     As ARC explained in the patent application, “[t]he described inflator also eliminates the requirement for simultaneous welds, which facilitates manufacturing and reduces potential weld particles.” 
                    <SU>121</SU>
                    <FTREF/>
                     In addition, the redesigned inflator included a pressure relief valve to create a failure mode that would avoid rupture if over pressurization occurred.
                    <SU>122</SU>
                    <FTREF/>
                     These representations and redesign efforts demonstrate that, at the same time ARC was insisting in the NHTSA investigation that the subject inflators were neither defective nor inappropriate in their performance, the company was actively trying to correct the problems with its inflators and conceding the existence of those problems to another agency in the United States government.
                </P>
                <FTNT>
                    <P>
                        <SU>120</SU>
                         For the subject inflators, ARC refers to this step of the manufacturing process as Operation 50 for the driver-side inflator and Operation 42 for the passenger-side inflator. 
                        <E T="03">See, e.g.,</E>
                         ARC Presentation on CADH Inflator Design.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>121</SU>
                         U.S. Pat. App. Pub. No. 2022/0185224 A1 to Rose 
                        <E T="03">et al.,</E>
                         at ¶ 0047.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>122</SU>
                         “The inflator also advantageously includes a pressure relief in the event of an elevated system internal pressure without any rupture of the inflator.” 
                        <E T="03">Id.</E>
                    </P>
                </FTNT>
                <P>
                    Ignoring the evidence of a common defect attributable to the friction welding process, certain commenters have nevertheless argued that there is, as of yet, no definitive, established “root cause.” 
                    <SU>123</SU>
                    <FTREF/>
                     While comments from two 
                    <PRTPAGE P="63485"/>
                    individuals supported NHTSA's identification of weld-flash evidence 
                    <SU>124</SU>
                    <FTREF/>
                     common to several of the ruptures, other commenters incorrectly suggested that, to establish a defect here, NHTSA must identify a more specific cause that is identical in each of the failures. Some of these comments hinge, at least in part, on the notion that a specific root cause of the defect in the Takata air bag inflators had been identified.
                    <SU>125</SU>
                    <FTREF/>
                     For example, Hyundai asserted that the agency's September 2023 initial decision was “entirely inconsistent with its decision-making in the Takata case,” citing in part a consensus root cause at the time of the Takata recall request letter.
                    <SU>126</SU>
                    <FTREF/>
                     Whether a particular recall had an identified cause before or at the time it was filed does not establish that such a particularized root cause is a requirement for a recall. It is not.
                    <SU>127</SU>
                    <FTREF/>
                    A “ `defect' includes any defect in 
                    <E T="03">performance,</E>
                     construction, component, or material of a motor vehicle or motor vehicle equipment.” 49 U.S.C. 30102(a)(3) (emphasis added). Accordingly, “a determination of `defect' does not require any predicate of a finding identifying engineering, metallurgical, or manufacturing failures. A determination of `defect' may be based exclusively on the 
                    <E T="03">performance record</E>
                     of the vehicle or component.” 
                    <E T="03">Wheels,</E>
                     518 F.2d at 432 (emphasis added); 
                    <E T="03">see also United States</E>
                     v. 
                    <E T="03">General Motors Corp.,</E>
                     841 F.2d 400, 413 (D.C. Cir. 1988) (explaining that a defect can be established by the performance record alone and does not require an engineering explanation).
                    <SU>128</SU>
                    <FTREF/>
                     A non-defective inflator does not rupture when it is commanded to deploy, absent some extraordinary circumstance such as tampering.
                    <SU>129</SU>
                    <FTREF/>
                     The repeated ruptures of the subject inflators would not have occurred absent a defect.
                    <SU>130</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>123</SU>
                         
                        <E T="03">See, e.g.,</E>
                         Comments of Kia America Inc. at pp. 1-2; Written Comments of General Motors LLC at p. 13; Comments from Hyundai Motor America at pp. 2, 20; Public Comment Submitted by Jacqueline Glassman at p. 10 (stating that while the root cause 
                        <PRTPAGE/>
                        “may not necessarily be a prerequisite to understanding that there is a safety related defect,” there must “be some meaningful relationship in order to infer that the underlying problem is a `class-wide' problem.”).
                    </P>
                    <P>This is despite the years of analysis the industry has undertaken during the agency's investigation. The agency does not believe that it is either necessary or appropriate to allow for additional time for such analysis.</P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>124</SU>
                         
                        <E T="03">See</E>
                         John Keller P.E., Comments on NHTSA's Initial decision to Declare ARC Automotive Toroidal Airbag Inflators Defective (Dec. 6, 2023) at p. 1; Jerry W. Cox, Esq., Comments in Support of the National Highway Traffic Safety Administration's Initial Decision to Declare 52 Million ARC Automotive Airbag Inflators Defective at p. 2.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>125</SU>
                         Commenters appear to overstate NHTSA's reliance on the Takata recalls as a basis for the initial decision here. Takata was discussed essentially twice in the initial decision: in a section providing general background on air bags and in another providing background on the agency's past practices regarding recall request letters. NHTSA's references to Takata in the initial decision were made to provide context on recalls involving inflator ruptures and not as a particularized substantive argument.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>126</SU>
                         In fact, NHTSA's recall request letter to Takata makes clear that the agency believed that multiple variables could result in propellant degradation, which caused ruptures. Letter from F. Borris, NHTSA, to K. Higuchi, TK Holdings Inc. (Nov. 26, 2014), 
                        <E T="03">https://static.nhtsa.gov/odi/inv/2014/INRM-PE14016-60978.pdf</E>
                         (describing high absolute humidity as one variable, but explaining that other ruptures occurred outside areas of high absolute humidity). That is also the case here, where the evidence points to multiple variables that may result in over pressurization, causing rupture.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>127</SU>
                         Pointing to the specific facts in the Takata recalls as precedent for 
                        <E T="03">necessary</E>
                         elements to order a recall, among other things, ignores that each recall is fact specific—and suggests, incorrectly, that the agency must match the bases for the Takata recalls to order a recall here.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>128</SU>
                         It is well established that a safety defect determination does not require an engineering explanation or root cause. 
                        <E T="03">See</E>
                         NHTSA Enforcement Guidance Bulletin 2016-02: Safety-Related Defects and Automated Safety Technologies, 81 FR 65705, 65708 (Sept. 23, 2016).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>129</SU>
                         
                        <E T="03">See</E>
                         NHTSA, 
                        <E T="03">Special Crash Investigations: On-Site Air Bag Inflator Rupture Crash Investigation; Vehicle: 2009 Honda Civic; Location: Maryland; Crash Date: September 2017</E>
                         (June 2020), 
                        <E T="03">https://crashstats.nhtsa.dot.gov/Api/Public/Publication/812972</E>
                         (explaining, in investigation into ruptured inflator, that “[t]he wiring harness for the driver's frontal air bag inflator had been tampered with since the vehicle's date of manufacture”).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>130</SU>
                         In much of the prior litigation under Safety Act the issue of whether there was a defect was not in question, in part due to the obvious nature of the defect. 
                        <E T="03">See, e.g., United States</E>
                         v. 
                        <E T="03">General Motors Corp.,</E>
                         561 F.2d 923, 924 (D.C. Cir. 1977) (“
                        <E T="03">Pitman Arms</E>
                        ”); 
                        <E T="03">United States</E>
                         v. 
                        <E T="03">Ford Motor Co.,</E>
                         453 F. Supp. 1240, 1249 (D.D.C. 1978).
                    </P>
                </FTNT>
                <P>
                    Manufacturers' arguments related to a “root cause” finding are inconsistent with their legal obligations and actions they have taken pursuant to those obligations. Under the Safety Act, a manufacturer is required to initiate a recall once it “learns the vehicle or equipment contains a defect and decides in good faith that the defect is related to motor vehicle safety.” 49 U.S.C. 30118(c)(1). It is common for the industry to recognize obvious defects without identifying a specific cause when, based on the performance record, they present a severe risk to safety.
                    <SU>131</SU>
                    <FTREF/>
                     Related to air bags in particular, manufacturers have recalled inflators susceptible to rupture without identifying the type of particularized cause demanded by the commenters.
                    <SU>132</SU>
                    <FTREF/>
                     In fact, ARC and other manufacturers have done so here. For example, BMW, GM, and Volkswagen initiated recalls without identifying a cause based on the severity of the risk as shown by one rupture.
                    <SU>133</SU>
                    <FTREF/>
                     ARC acknowledged that it has “supported targeted recalls by vehicle manufacturers related to field ruptures and production lots with an identified potential risk of defect.” 
                    <SU>134</SU>
                    <FTREF/>
                     These actions are consistent with a manufacturer's obligations under the Safety Act to recall vehicles when it decides a defect related to motor vehicle safety exists. The Safety Act does not allow a manufacturer to evade or delay a recall because it has not identified a specific “root cause.” NHTSA routinely takes enforcement actions against manufacturers for failure to timely make recall determinations, including where the lack of an identified root cause contributed to the delay.
                    <SU>135</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>131</SU>
                         
                        <E T="03">See</E>
                         Defect Notices, NHTSA Recall Nos. 23V-867 (In describing the cause of the defect that “may lead to thermal overload, possibly resulting in smoke or a fire,” Volkswagen stated that “[t]he root cause is still under investigation, but the risk is associated with the battery modules exhibiting the potentially critical self-discharge behavior.”); 23V-840 (In its description of the cause of a defect that “can lead to thermal events and in some cases fires,” Porsche states that “[t]he root cause is still under investigation.”); 23V-369 (JLR provides “NR,” commonly understood to mean `no response,' to describe the cause of a “thermal overload” condition that “may show as smoke or fire” and “can result in increased risk of occupant injury.”); 23V-626 (In determining a defect exists that can “result in a loss of motive power,” Ford identified one contributing factor but stated that “a second factor must be present or induced,” and that “[t]his factor is still unknown and under investigation.”); 24V-099 (For a defect affecting seatbelt function that “may result in injury in the event of a crash,” Ford attributed the issue to corrosion “caused by an undefined supplier manufacturing issue.”); and 24V-418 (For a defect resulting in seatbelts becoming “unavailable as an occupant restraint” and resulting in “an increased risk of injury if the vehicle is involved in a crash,” GM describes the cause as “[t]wo internal components” that “may be slightly our of dimensional specifications” but does not explain how the components came to be out of specifications.)
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>132</SU>
                         
                        <E T="03">See</E>
                         Defect Notice, NHTSA Recall No. 16V-045 (“The cause is yet not determined. Takata and Volkswagen are still under investigation of the root cause.”).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>133</SU>
                         
                        <E T="03">See</E>
                         Defect Notices, NHTSA Recall Nos. 17V-189 (“The root cause has not yet been determined and is still under investigation.”); 19V-019 (providing no response (“NR”) as to the description of the cause); 21V-782 (providing no response (“NR”) as to the description of the cause); 22E-040 (“GM's investigation has not identified the specific root cause of the LAT rupture”); 22V-246 (providing no response (“NR”) as to the description of the cause); 22V-543 (“The root cause is currently unknown . . . .”). Even in GM's most recent ARC-related recall, which it no longer sought to limit to a specific production lot, it indicated as to cause that “GM is continuing its investigation into this incident.” 
                        <E T="03">See</E>
                         Defect Notice, NHTSA Recall No. 23V-334.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>134</SU>
                         
                        <E T="03">See</E>
                         Written Response of ARC Automotive, Inc. to the September 5, 2023, Initial Decision Docket No. NHTSA-2023-0038 at p. 20, 
                        <E T="03">https://www.regulations.gov/comment/NHTSA-2023-0038-0027.</E>
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>135</SU>
                         
                        <E T="03">See, e.g.,</E>
                         Consent Order between NHTSA and Daimler Trucks North America, LLC, In re: AQ18-002 ¶ 29 (Dec. 29, 2020), 
                        <E T="03">https://www.nhtsa.gov/sites/nhtsa.gov/files/documents/aq18-002_consent_order_executed.pdf</E>
                         (“DTNA acknowledges that the failure to identify a specific root cause, develop an adequate repair or remedy, or confirm the affected population of vehicles are not bases for delaying the identification of a defect or noncompliance, the determination of whether a defect related to motor vehicle safety, or the timely reporting a defect or 
                        <PRTPAGE/>
                        noncompliance to NHTSA.”); Consent Order between NHTSA and General Motors Company, In re: TQ14-001 ¶ 24 (May 16, 2014), 
                        <E T="03">https://www.nhtsa.gov/sites/nhtsa.gov/files/2021-11/TQ14-001-General-Motors-Consent-Order-5-6-2014-tag.pdf</E>
                         (“GM shall not delay holding any meeting . . . to decide whether or not to recommend or. conduct a safety recall because GM has not yet identified the precise cause of a defect, a remedy for the defect, or prepared a plan for remedying the defect.”).
                    </P>
                </FTNT>
                <PRTPAGE P="63486"/>
                <P>Commenters' arguments regarding root cause also ignore the evidence of a common defect collected during NHTSA's investigation and described above in this section and II.A.2-3 &amp; 5. The evidence indicates that problems related to friction welding can lead to both over-pressurization due to exit orifice blockage and insufficient friction welds. All of the field ruptures and a majority of the lot acceptance test ruptures share these commonalities.</P>
                <P>The evidence collected in NHTSA's investigation establishes that the subject inflators have an unacceptable risk of rupturing. Therefore, the entire subject inflator population is defective and must be recalled. As demonstrated by past ruptures, the occurrence of a rupture is unpredictable. Ruptures have occurred outside of narrower inflator populations previously identified by the manufacturers to be the defective population. There is substantial evidence tying the defect to the friction welding process, and this process was used across all manufacturing lines and plants that produced the subject inflators. After multiple years of thorough investigation and analysis, the evidence does not identify another element linking the ruptures. As such, the subject inflator population identified in this decision is the narrowest defective population supported by the evidence.</P>
                <P>
                    ARC claims the subject inflator population is too broad due to variations in design and manufacturing of the subject inflators. Similarly, other commenters have pointed out these variations and assert that certain subpopulations of the subject inflators should be excluded from the scope of a recall, 
                    <E T="03">e.g.,</E>
                     passenger-side subject inflators and subject inflators installed in certain makes and models. Despite years of comprehensive analysis, NHTSA has found no design or manufacturing evidence that shows these subpopulations are less susceptible to rupture. In addition to the field rupture of a passenger-side inflator, passenger-side inflators also ruptured in fourteen lot acceptance tests. While NHTSA recognizes there may be practical and logistical challenges to implementing a recall for the full defective population, these concerns do not warrant a narrower scope. Under the Safety Act, unreasonable risks cannot be countenanced simply because of logistical challenges that may be involved in remedying them.
                </P>
                <P>
                    None of the manufacturers have provided compelling technical evidence that connects any of these variations to the defect or to a particular subset of inflators that rebuts the need to recall the subject inflators, “[a]nd there is justice in this allocation to the manufacturer[s] of the burden of compiling significant data on the causes and consequences of mishaps in [their] cars.” 
                    <E T="03">United States</E>
                     v. 
                    <E T="03">General Motors Corp.,</E>
                     561 F.2d 923, 931 (D.C. Cir. 1977) (“
                    <E T="03">Pitman Arms”</E>
                    ). And contrary to Hyundai's comment that there is “little downside” for the agency to “complete the necessary investigation and make a rational judgment as to whether” and to what extent a recall is needed, there is already sufficient evidence that the full population of subject inflators is defective. There is significant “downside” at this point to further investigation in lieu of a recall.
                    <SU>136</SU>
                    <FTREF/>
                     Absent a recall, vehicle owners are not notified of the defect or entitled to have it addressed when a remedy is available. NHTSA has, accordingly, initially determined that the full population of subject inflators is defective.
                </P>
                <FTNT>
                    <P>
                        <SU>136</SU>
                         Hyundai also noted that “no other country with a similar safety recall legal framework” has required a recall for the subject inflators. There are seven confirmed U.S. ruptures of the subject inflators, and over 20 million fewer ARC inflators were distributed globally (across 
                        <E T="03">all</E>
                         countries) than to the U.S. In any case, NHTSA's action is based on U.S. law. NHTSA is not bound by other jurisdictions and their respective authorities and is making this decision based on the facts before it (all of which may, or may not, be available to other jurisdictions).
                    </P>
                </FTNT>
                <HD SOURCE="HD2">B. The Defect Is Related to Motor Vehicle Safety</HD>
                <P>NHTSA has also preliminarily concluded based on the available evidence that the defect in the subject inflators (as described in section II.A) is related to motor vehicle safety because a risk of inflator rupture presents an unreasonable risk of death or injury in the event of an accident. It is undisputed that rupturing inflators have forcefully propelled pieces of metal at occupants, resulting in grave, permanent injuries and death. Future rupture events likely would have similar outcomes. An air bag's life-saving purpose also has bearing on the unreasonableness of this defect.</P>
                <P>The Safety Act defines “motor vehicle safety” as “the performance of a motor vehicle or motor vehicle equipment in a way that protects the public against unreasonable risk of accidents occurring because of the design, construction, or performance of a motor vehicle, and against unreasonable risk of death or injury in an accident and includes nonoperational safety of a motor vehicle.” 49 U.S.C. 30102(a)(9). The statute does not further define what constitutes an “unreasonable risk.” Based on the ordinary meaning of that term, the high severity of an inflator rupture coupled with the inability of a vehicle owner or occupant to detect that the rupture will occur or otherwise mitigate the risk warrants a finding that the risk is unreasonable despite the low probability that a rupture will occur when the inflator is commanded to deploy.</P>
                <P>
                    In considering this issue, courts have found that an assessment of whether a risk is unreasonable requires a “ `commonsense' approach.” 
                    <E T="03">Carburetors,</E>
                     565 F.2d at 757. The most obvious, or “commonsense,” consideration in this assessment is, of course, the safety risk itself. A defect that “leads to failures in a vital component . . . is prima facie an `unreasonable risk.' ” 
                    <E T="03">Pitman Arms,</E>
                     561 F.2d at 929. In other words, there is “no question” that a risk of an “extremely dangerous” situation “should be considered an unreasonable risk to safety.” 
                    <E T="03">Carburetors</E>
                     at 757. If the risk is sufficiently severe, even an “exceedingly small” or “negligible” number of expected incidents is “unreasonably large.” 
                    <E T="03">Id.</E>
                     at 759.
                    <SU>137</SU>
                    <FTREF/>
                     This is so regardless of whether any injuries have already occurred, or whether the projected number of failures or injuries in the future is trending down. 
                    <E T="03">See id.</E>
                </P>
                <FTNT>
                    <P>
                        <SU>137</SU>
                         Commenters asserted that NHTSA did not use or follow risk matrices used by NHTSA's Office of Defects Investigation (ODI). NHTSA's risk matrices are not recall-determination tools. Rather, the matrices are used “[t]o assist in objectively evaluating whether a potential defect issue should be advanced to the next stage for an investigation. . . . ODI uses these matrices as deliberative tools to assist in evaluating the risk posed by a potential defect and identifying issues that should be elevated to an investigation.” Risk-Based Process for Safety Defect Analysis and Management of Recalls, DOT HS 812 984 (Nov. 2020), 
                        <E T="03">https://www.nhtsa.gov/sites/nhtsa.gov/files/documents/14895_odi_defectsrecallspubdoc_110520-v6a-tag.pdf.</E>
                         NHTSA decided back in 2015 that this issue warranted investigation under its risk-based processes. Further, ODI's risk matrices and their application are not binding on NHTSA or any outside entity, and they are not “guidance”; they are a tool for ODI personnel.
                    </P>
                </FTNT>
                <P>
                    Courts have also considered certain particularly severe defects to be “per se” safety-related defects regardless of how many injuries or accidents are likely to occur in the future. These decisions have involved defects that cause the failure of a critical component, a vehicle fire, a loss of vehicle control, and a 
                    <PRTPAGE P="63487"/>
                    defect that suddenly moves the driver away from the steering wheel, accelerator, and brake controls. 
                    <E T="03">See Carburetors,</E>
                     565 F.2d 754 (engine fires); 
                    <E T="03">Pitman Arms,</E>
                     561 F.2d 923 (loss of control); 
                    <E T="03">United States</E>
                     v. 
                    <E T="03">Ford Motor Co.,</E>
                     453 F. Supp. 1240 (D.D.C. 1978) (“
                    <E T="03">Wipers</E>
                    ”) (loss of visibility); 
                    <E T="03">United States</E>
                     v. 
                    <E T="03">Ford Motor Co.,</E>
                     421 F. Supp. 1239, 1243-44 (D.D.C. 1976) (“
                    <E T="03">Seatbacks</E>
                    ”) (loss of control); 
                    <E T="03">see also</E>
                     NHTSA, 
                    <E T="03">Motor Vehicle Safety Defects and Recalls: What Every Vehicle Owner Should Know, available at</E>
                      
                    <E T="03">https://www.nhtsa.gov/sites/nhtsa.gov//documents/14218-mvsdefectsandrecalls_041619-v2-tag.pdf</E>
                     (providing examples of safety-related defects, including “[a]ir bags that deploy under conditions for which they are not intended to deploy” and “[c]ritical vehicle components that break, fall apart, or separate from the vehicle, causing potential loss of vehicle control or injury to people inside or outside the vehicle”).
                </P>
                <HD SOURCE="HD3">1. The Risk Posed by an Inflator Rupture Is Severe</HD>
                <P>
                    Here, there is no question that an inflator rupture presents an extreme danger. As already described, a rupture turns a component with the sole purpose of preventing serious injury and death into a device that can cause serious injury or death; the defect simultaneously undermines the component's life-saving purpose and introduces a life-threatening danger. To reiterate, the consequences of these ruptures thus far include lacerations to the legs, harm to the jaw and ear, severe injuries to the face, neck, head, shoulder, and arm, injury to the airway requiring a tracheostomy, and death. Commonsense dictates that the defect here poses an unreasonable risk. 
                    <E T="03">See Carburetors,</E>
                     565 F.2d at 757-59.
                </P>
                <P>
                    Even if a vehicle occupant is fortunate enough not to be struck by the metal fragments ejected out of the inflator upon a rupture, the rupture also undermines the intended effectiveness of the air bag in protecting an occupant in a crash. An air bag is designed to deploy in a precise manner under very strict timeframes. Over the course of milliseconds, numerous vehicle systems working in tandem must perform a multitude of functions in a particular order to ensure that the airbag protects the occupant.
                    <SU>138</SU>
                    <FTREF/>
                     An air bag inflator is a critically important component in this sequence as it is responsible for ensuring that an air bag inflates a precise amount at a precise time in order to be in the right position when it meets the vehicle's occupant. When an inflator ruptures, the pressure accumulating in the inflator to is suddenly released, resulting in a complete disruption of the tightly controlled gas flow intended for the inflator.
                    <SU>139</SU>
                    <FTREF/>
                     This disrupts the air bag inflation timing, undermining the air bag's ability to perform its intended safety function. Thus, even apart from a rupture's dangerous explosion of metal fragments towards a vehicle occupant, the rupture deprives a vehicle occupant of the benefit of an air bag.
                    <SU>140</SU>
                    <FTREF/>
                     Manufacturers have issued recalls to address the increased safety risk to vehicle occupants when air bags do not properly inflate.
                    <SU>141</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>138</SU>
                         Such functions include but are not limited to detecting an impact, classifying the impact as severe enough to warrant an air bag deployment, understanding the likely positioning of the vehicle occupant based on the occupant's seating position and seatbelt status, commanding deployment of the air bag at a specified inflation rate to match the occupant's expected position, and reaching a level of air bag inflation necessary for the cushion of the air bag to reduce the expected crash forces. This is a very complex dynamic in which numerous life-critical systems are interdependent and all components must perform exactly as intended to protect the vehicle occupants.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>139</SU>
                         This release causes the gas flow rate into the air bag to suddenly spike before dramatically dropping as the inflator's pressure equalizes with the ambient air.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>140</SU>
                         During the investigation, both ARC and at least one vehicle manufacturer acknowledged that the rupture of one of the subject inflators could cause an air bag to underinflate. 
                        <E T="03">See</E>
                         ARC Presentation dated Mar. 1, 2016 on MY 2004 Kia Optima Rupture; Hyundai Letter to NHTSA dated Apr. 15, 2020.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>141</SU>
                         
                        <E T="03">See</E>
                         NHTSA Recall Nos. 12V-055 and 01V-318.
                    </P>
                </FTNT>
                <P>
                    Hundreds of recalls are issued each year for safety-related defects. In 2023 alone, there were nearly 800 such vehicle recalls. The vast majority of these recalls were uninfluenced by a NHTSA investigation.
                    <SU>142</SU>
                    <FTREF/>
                     The nature of the defects and potential consequences ranged widely. While some involved fire risks or loss of vehicle control (and certain such recalls were accompanied by a “do not drive” advisory), others involved a variety of components and other potential consequences: sun visors that may detach (may distract or obstruct view); aluminum siding that may detach from a trailer; incorrectly assembled door latches that may allow the door to open unexpectedly during operation; incorrectly installed headlights (reducing visibility); and detached rearview mirror lenses (reducing visibility).
                    <SU>143</SU>
                    <FTREF/>
                     When viewed broadly against the backdrop of the hundreds of recalls issued each year for various types of components and attendant consequences, the severity of an inflator rupture—where the consequence of the defect is the projection of shrapnel into the occupant compartment—is extreme. The latent nature of the defect further exacerbates its severity. This defect cannot be discerned by a diligent vehicle owner or even as the result of an inspection. The defect only becomes apparent upon a deployment but, by then, the danger has already manifested. As a result, this defect provides no opportunity for a driver to take any mitigating actions absent a recall—either ahead of manifestation of the defect, or when the defect manifests.
                </P>
                <FTNT>
                    <P>
                        <SU>142</SU>
                         NHTSA 2023 Annual Report: Safety Recalls (Mar. 2024), 
                        <E T="03">available at https://www.nhtsa.gov/sites/nhtsa.gov/files/2024-03/NHTSA-2023-Annual-Recalls-Report_0.pdf.</E>
                         “Uninfluenced” recalls are recalls issued by a manufacturer not influenced by NHTSA investigation into the issue.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>143</SU>
                         
                        <E T="03">See</E>
                         NHTSA Recall Dashboard, 
                        <E T="03">https://datahub.transportation.gov/Automobiles/NHTSA-Recalls-by-Manufacturer/mu99-t4jn;</E>
                         Recall Nos. 23V-781, 23V-612, 23V-373, 23V-650, 23V-856. The recall dashboard is a user-friendly platform that can be used to sort, filter, visualize, and export recall data.
                    </P>
                </FTNT>
                <P>
                    The air bag inflator industry itself has long recognized the severity of the risk posed by an inflator rupture and the importance of preventing it. The United States Council for Automotive Research (USCAR) has published specifications establishing performance and validation requirements for air bag inflators. These requirements include assurance against certain behaviors in the event of an inflator rupture, which USCAR refers to as a burst. The specifications provide a testing procedure to confirm the structural integrity of an inflator, instructing the tester to block any exit orifices and increase the pressure until the inflator ruptures.
                    <SU>144</SU>
                    <FTREF/>
                     This test is to ensure that “[a]n Inflator shall not eject any components or fragments during any portion of [design validation] and [production validation] testing.” 
                    <SU>145</SU>
                    <FTREF/>
                     In the event of a rupture, any separation must be ductile and “the inflator shall not fragment or eject any part of the structural components.” 
                    <SU>146</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>144</SU>
                         USCAR Inflator Technical Requirements and Validation at p. 30 ¶ 5.2.3.1 (SAE Int'l, 2023).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>145</SU>
                         
                        <E T="03">Id.</E>
                         at p. 7 ¶ 3.2.2.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>146</SU>
                         
                        <E T="03">Id</E>
                         at p. 7 ¶ 3.2.2.1.
                    </P>
                </FTNT>
                <P>
                    ARC's own design practices similarly recognize that inflator ruptures present an unacceptable level of risk. Similar to the USCAR specifications described above, ARC's own internal mistake proofing protocol acknowledged that it was critical during the Operation 50 step of the manufacturing process to ensure that “no vent orifice or weld flash blockage” occurred.
                    <SU>147</SU>
                    <FTREF/>
                     This is because ARC recognized that if those conditions exist, “[t]he inflator can “over pressurize and result in parts 
                    <PRTPAGE P="63488"/>
                    ejecting.” 
                    <SU>148</SU>
                    <FTREF/>
                     ARC assigned this type of over pressurization and rupture an FMEA severity number of 10 out of 10—the highest level of severity of all risks in ARC's FMEA. Any inflators in which such blockage occurred were to be “manually scrapped” and prompt a supervisor notification. As these materials illustrate, at the design and manufacturing planning stages, ARC expected a strict lack of tolerance for conditions that created a risk of ruptures, out of concern for the precise dangers at issue in this proceeding.
                </P>
                <FTNT>
                    <P>
                        <SU>147</SU>
                         
                        <E T="03">See</E>
                         ARC Response to Requests 2 &amp; 3 of NHTSA Aug. 25, 2015 IR Letter at p. 40.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>148</SU>
                         
                        <E T="03">Id.</E>
                    </P>
                </FTNT>
                <P>
                    As previously discussed in section II.A.6, manufacturers in the instant case have also recognized the severity of the defective inflators in several ways. A single rupture was enough to prompt BMW, GM, and Volkswagen to issue recalls.
                    <SU>149</SU>
                    <FTREF/>
                     Some manufacturers engaged private research firms to try to better understand the defect.
                    <SU>150</SU>
                    <FTREF/>
                     In an effort to eliminate this severe risk from future inflators with the same design as the subject inflators, ARC implemented the automated borescope on all of its toroidal air bag inflator manufacturing lines.
                    <SU>151</SU>
                    <FTREF/>
                     Going a step further, ARC has taken steps to remove the potential for this defect and the associated risk by considering other inflator designs.
                    <SU>152</SU>
                    <FTREF/>
                     All of these actions underscore the commonsense recognition that a piece of equipment intended to protect people from injury and save lives that, instead, explodes and propels metal toward vehicle occupants presents an unreasonable risk to motor vehicle safety.
                </P>
                <FTNT>
                    <P>
                        <SU>149</SU>
                         
                        <E T="03">See</E>
                         Defect Notices, NHTSA Recall Nos. 17V-189, 
                        <E T="03">https://static.bnhtsa.gov/odi/rcl/2017/RCLRPT-17V189-8204.PDF</E>
                         (“The root cause has not yet been determined and is still under investigation.”); 19V-019, 
                        <E T="03">https://static.nhtsa.gov/odi/rcl/2019/RCLRPT-19V019-2023.PDF</E>
                         (providing no response (“NR”) as to the description of the cause); 21V-782, 
                        <E T="03">https://static.bnhtsa.gov/odi/rcl/2021/RCLRPT-21V782-3621.PDF</E>
                         (providing no response (“NR”) as to the description of the cause); 22E-040, 
                        <E T="03">https://static.nhtsa.gov/odi/rcl/2022/RCLRPT-22E040-9723.PDF (“</E>
                        GM's investigation has not identified the specific root cause of the LAT rupture”); 22V-246, 
                        <E T="03">https://static.bnhtsa.gov/odi/rcl/2022/RCLRPT-22V246-3538.PDF</E>
                         (providing no response (“NR”) as to the description of the cause); 22V-543, 
                        <E T="03">https://static.nhtsa.gov/odi/rcl/2022/RCLRPT-22V543-3225.pdf</E>
                         (“The root cause is currently unknown . . . .”). Even in GM's most recent ARC-related recall, which it no longer sought to limit to a specific production lot, it indicated as to cause that “GM is continuing its investigation into this incident.” 
                        <E T="03">See https://static.bnhtsa.gov/odi/rcl/2023/RCLRPT-23V334-3445.PDF.</E>
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>150</SU>
                         
                        <E T="03">See</E>
                         Northrop Grumman Presentation dated May 5, 2023 on GM ARC Inflator Investigation; Memorandum—Meeting with HMA with Enclosure, Docket No. NHTSA-2023-0038, 
                        <E T="03">https://www.regulations.gov/document/NHTSA-2023-0038-0029.</E>
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>151</SU>
                         
                        <E T="03">See</E>
                         ARC Working Group 8D Technical Closure Statement at p. 1.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>152</SU>
                         
                        <E T="03">See</E>
                         U.S. Pat. App. Pub. No. 2022/0185224 A1 to Rose 
                        <E T="03">et al.,</E>
                         at ¶¶ 0005-06.
                    </P>
                </FTNT>
                <P>
                    Some commenters contended that the “commonsense” approach to the assessment of unreasonable risk requires a cost consideration, and that NHTSA did not consider costs in issuing its decision. This contention is essentially based on language in 
                    <E T="03">Wheels,</E>
                     in which the U.S. Court of Appeals for the D.C. Circuit discussed an approach to safety in the context of defects—specifically, a “ 'commonsense' balancing of safety benefits and economic cost” that recognizes that “manufacturers are not required to design vehicles or components that never fail.” The court stated that “[i]t would appear economically, if not technologically, infeasible for manufacturers to use tires that do not wear out, lights that never burn out, and brakes that do not need adjusting or relining. Such parts cannot reasonably be termed defective if they fail because of age and wear.” 
                    <E T="03">Wheels,</E>
                     518 F.2d at 435-36.
                </P>
                <P>
                    The subject air bag inflators are not the type of “wear and tear” component to which the cost consideration described in 
                    <E T="03">Wheels</E>
                     would be apposite. Similar to the defective component in 
                    <E T="03">Carburetors,</E>
                     “[h]ere we do not deal with a part which is subject to failure because of age and wear, or a part which drivers reasonably expect to have to check and replace because of the particular problem involved.” 
                    <E T="03">Carburetors,</E>
                     565 F.2d at 759-60. The inflator industry already designs inflators never to rupture. In any case, by requiring a recall of the subject inflators, the agency is not requiring manufacturers to produce “perfect, accident-free vehicles at any expense.” 
                    <E T="03">See Carburetors,</E>
                     565 F.2d at 760. Rather, it is requiring the notification of owners about these inflators “which did not, from the beginning, meet the manufacturer's own standards.” 
                    <E T="03">See id.</E>
                     at 760.
                </P>
                <HD SOURCE="HD3">2. Future Inflator Ruptures Are Expected</HD>
                <P>
                    As the agency observed in its September 2023 initial decision, new ruptures have occurred outside of the sub-populations of vehicles previously recalled, and it is expected that additional ruptures will occur in the future. 
                    <E T="03">See Carburetors,</E>
                     565 F.2d at 758 (“[W]here a defect—a term used in the sense of an `error or mistake'—has been established in a motor vehicle, and where this defect results in hazards as potentially dangerous as a sudden engine fire, and where there is no dispute that at least some such hazards, in this case fires, can definitely be expected to occur in the future, then the defect must be viewed as one `related to motor vehicle safety.' ”) (footnotes omitted). However, just as the agency (and manufacturers) could not have predicted the vehicles in which ruptures have already occurred, nor can it predict the vehicles in which ruptures will occur for vehicles that remain equipped with subject inflators. Each of those inflators remains at risk. What is predictable is that the consequences of a rupture will be severe and possibly deadly. Thus, even though the risk of any individual inflator rupturing is low, it is nevertheless unreasonable. “The purpose of the Safety Act . . . is not to protect individuals from risks associated with defective vehicles only after serious injuries have already occurred; it is to prevent serious injuries stemming from established defects before they occur.” 
                    <E T="03">Id.</E>
                     at 759.
                </P>
                <P>
                    NHTSA is supplementing its statistical evaluation of the rupture risk of the subject inflators as a result of several adjustments made since the initial decision and partially as informed by the comments received.
                    <SU>153</SU>
                    <FTREF/>
                     Upon additional analysis, NHTSA finds that the subject inflators have a higher risk of rupture than initially believed, based on a lowered estimate of the number of subject inflators that have previously deployed in the field. NHTSA's estimate is based on 38,480,407 vehicles that have subject inflators in the driver-side air bag only, 8,992,543 vehicles that have subject inflators in the passenger-side air bag only, and 1,873,066 vehicles that have subject inflators in both driver- and passenger-side air bags, totaling approximately 49 million vehicles. NHTSA now estimates that 1,349,802 of the subject air bag inflators (combined driver-side and passenger-side) deployed in vehicles between 2000 and 2023.
                    <SU>154</SU>
                    <FTREF/>
                     Based on the known field ruptures, the rupture rate of the subject inflators is therefore 7 out of 1,349,802. In other words, the risk of any subject inflator rupturing when commanded to deploy was and is 1 in 192,829.
                    <SU>155</SU>
                    <FTREF/>
                     NHTSA is adding to the docket a report more fully explaining its statistical considerations and findings. 
                    <E T="03">See</E>
                     NHTSA, 
                    <E T="03">
                        Estimating the Rupture Rate and Projecting Future Ruptures for 
                        <PRTPAGE P="63489"/>
                        Subject Inflators in NHTSA's Proceeding Related to EA16-003.
                    </E>
                </P>
                <FTNT>
                    <P>
                        <SU>153</SU>
                         Changes include applying different deployment rates to driver- and passenger-side inflators based on historical crash data, refining the classification of vehicles for purposes of accounting for attrition, and accounting for vehicles being driven fewer miles as they age. These changes address a number of comments directed at this analysis.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>154</SU>
                         NHTSA previously estimated that approximately 2,600,000 of the subject air bag inflators had deployed in the field.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>155</SU>
                         This is an increase from the prior estimate of 7 in 2.6 million (or 1 in 371,429).
                    </P>
                </FTNT>
                <P>
                    NHTSA does not conduct statistical analyses as a matter of course in every defect investigation. Nor was a statistical analysis strictly necessary here—particularly given that the unreasonable risk here is self-evident and one of “common sense.” The analysis was initiated in response to a statement by ARC. In its response to the agency's recall request letter, ARC asserted that seven ruptures as compared to the total subject inflator population was insufficient to determine that a defect exists in the subject inflator population.
                    <SU>156</SU>
                    <FTREF/>
                     However, a rupture only occurs if the air bag deploys. As such, it is more appropriate and accurate to compare the number of past field ruptures to the number of past field deployments to determine the rate at which the subject inflators have ruptured. Determining an estimated number of past field deployments required statistical calculations, which yielded the initial analysis. NHTSA disagrees with General Motors' characterization of NHTSA's reliance on that statistical analysis as “heavy.” Indeed, the analysis was previously addressed in just a few sentences of NHTSA's September 2023 initial decision.
                    <SU>157</SU>
                    <FTREF/>
                     The statistical analysis, now updated, is not a prediction of the future. It is, rather, additional information that supplements the agency's ordinary consideration of what constitutes an unreasonable risk, including engineering and investigative evidence. Although it supports NHTSA's conclusion, the statistical analysis was not necessary to NHTSA's September 2023 initial decision. That remains the case here as well.
                    <SU>158</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>156</SU>
                         ARC's May 11, 2023 Response to NHTSA's Recall Request Letter, p. 2, 
                        <E T="03">https://static.nhtsa.gov/odi/inv/2016/INRR-EA16003-90616.pdf.</E>
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>157</SU>
                         A NHTSA statistician also further explained her work, in the interest of transparency, at the October 2023 public meeting.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>158</SU>
                         GM asserted that NHTSA's statistical analysis is inconsistent with the agency's previous rejection of an earlier, separate statistical analysis (which GM characterizes as a “much more sophisticated predictive model”) in a previously submitted petition for inconsequentiality. 
                        <E T="03">See</E>
                         85 FR 76159 (Nov. 27, 2020) (decision on petition). The statistical analysis that GM provided in its previous inconsequentiality petition was submitted to support the argument that the defect in an air bag inflator (
                        <E T="03">i.e.,</E>
                         an air bag inflator 
                        <E T="03">in which a defect had already been determined to exist</E>
                        ) was, nonetheless, inconsequential to motor vehicle safety as installed in GM vehicles.
                    </P>
                </FTNT>
                <P>
                    While NHTSA's updated statistical analysis confirms the commonsense understanding that inflator ruptures will continue to be rare, the severity of rupture renders that risk unacceptable under the Safety Act. Unsurprisingly, the manufacturers who have continued to dispute the need for a broader recall disagree that the risk is unreasonable. A number of commenters challenged the persuasiveness of the future rupture risk, asserting that the estimated number of future ruptures is too low to present an unreasonable risk to motor vehicle safety. Comments emphasizing the low number of expected future ruptures are unconvincing. Up to this point, the subject inflators have ruptured rarely, and yet they have still injured or killed at least eight people in the United States. The evidence is sufficient for the agency to find that the rare, though expected, occurrence of future rupture is unreasonable given the severity. Under the plain language of the Safety Act, such a severe, undetectable, and unpredictable risk of an inflator rupturing and sending shrapnel at high speed into the occupant compartment of a vehicle is “unreasonable.” Even a “negligible” number of future ruptures is unreasonable given that a foreseeable outcome is severe injury or death. 
                    <E T="03">See Carburetors,</E>
                     565 F.2d 754 at 759; 
                    <E T="03">Pitman Arms,</E>
                     561 F.2d at 924.
                </P>
                <P>
                    While an inflator rupture occurs if the inflator has been commanded to deploy in a crash, several commenters nevertheless asserted that the relevant population of inflators from which to derive a rupture rate should be the entire subject inflator population (51 million, rather than the number of inflators estimated to have actually deployed). The reasons were varied, including that all inflators have the same potential to undergo deployment and rupture in a crash, that use of the entire population best accounts for both the risk of a deployment and the risk of a rupture and, as commented by ARC, “permits a more accurate comparison to peer inflator data and more appropriately compares the risk to comparable peer populations.” 
                    <SU>159</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>159</SU>
                         Written Response of ARC Automotive, Inc. to the September 5, 2023, Initial Decision (Dec. 18, 2023 (Corrected—February 12, 2024), at p. 23. ARC also asserted that such an approach would be based on two directly observable inputs (number of inflators and known field events) instead of one (number of field events) with a separate estimated input (deployments). 
                        <E T="03">See id.</E>
                         at p. 22. Whether an input is “directly observable” has little import in determining appropriate variables to use as a statistical matter in developing risk assessments. While the total inflator population may be more accurately estimated, that does not render it the more appropriate metric.
                    </P>
                </FTNT>
                <P>
                    NHTSA agrees that, in the event of a deployment, each of the subject inflators is equally at risk of rupture. None can be eliminated as not at risk, and it is not possible to know whether a particular inflator will rupture unless a deployment occurs. But a deployment is a necessary condition for a failure, and the vast majority of inflators have not deployed. Including the entire population of manufactured inflators in deriving a rupture rate—knowing that the overwhelming majority have not deployed—vastly understates the prevalence of the defect by ignoring the necessary condition for a failure. This would lead to a vast understatement of the true rupture rate and predicted future ruptures. For this reason, it is wholly appropriate to ground the predicted future rupture rate with reference to ruptures experienced in past deployments, and not to the total number of manufactured inflators.
                    <SU>160</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>160</SU>
                         General Motors refers to a previous investigation regarding Mini Cooper S exhaust pipe tips in which the total population was used to refer to a failure rate. The product at issue there, however, did not involve a necessary condition like a deployment of the subject air bags for the defect to manifest. And notably, in previously evaluating certain statistical analyses in a General Motors inconsequentiality petition regarding Takata air bag inflators, NHTSA described the risk at issue in terms consistent with that here. 
                        <E T="03">See</E>
                         85 FR 76159 (Nov. 27, 2020) (describing the fleet-level risk as “the probability that at least one air bag will rupture among the thousands of air bag deployments expected to occur in the nearly 5.9 million affected GMT900 vehicles over the coming years”).
                    </P>
                </FTNT>
                <P>
                    The notion that the total population of inflators allows for better peer comparison is also unconvincing. As explained above in II.A.4, there has been only one U.S. rupture of a non-Takata air bag inflator (other than an ARC air bag inflator), and any reference to the comparative rupture rates is of limited import, because that inflator was recalled after the first rupture. Therefore, it is unknown whether ruptures would have continued to occur in the absence of a recall. As is the case here, NHTSA believed the risk was unreasonable and a recall was warranted. The severity of inflator ruptures was also evident there, as the rupture resulted in a fatality. In that case, however, the manufacturer agreed to broad recalls of entire models (all model years) of vehicles that used the same type of inflator without the need for the agency to exercise its statutory authority to order a recall.
                    <SU>161</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>161</SU>
                         
                        <E T="03">See</E>
                         NHTSA Recall Nos. 20V-681, 21V-766, and 21V-800.
                    </P>
                </FTNT>
                <P>
                    Some commenters asserted that NHTSA improperly assumed that manufacturing variables in different variants of the subject inflators have no impact on the rupture rate. However, there is no evidence-based justification for treating any subpopulation of the subject inflators as presenting more or less risk. FCA stated that certain field ruptures should not be included in the analysis—the ruptures in the MY 2002 Chrysler Town &amp; Country and the MY 
                    <PRTPAGE P="63490"/>
                    2011 Chevrolet Malibu—because of these incidents did not have an underlying cause or failure mode in common with the other ruptures.
                    <SU>162</SU>
                    <FTREF/>
                     NHTSA does not agree that these incidents lack sufficient commonality to be considered, as described in section II.A. Additionally, as previously explained, root cause is not necessary for a defect determination. It is not appropriate to eliminate any of the ruptures in vehicles—the very incidents where people have already been harmed—from its evaluation of whether there is an unreasonable risk.
                </P>
                <FTNT>
                    <P>
                        <SU>162</SU>
                         
                        <E T="03">See</E>
                         Comments of FCA US LLC Regarding Initial Decision at pp. 5-6.
                    </P>
                </FTNT>
                <P>
                    Consumer safety “would be most ill served by extending [a] delay based on new predictions that the number of injuries caused by the defect will diminish.” 
                    <E T="03">Carburetors,</E>
                     565 F.2d at 759. The agency also does not believe that logistical and cost-related concerns raised by commenters about a recall of the subject inflators warrants leaving the unreasonable risk unaddressed by a recall. NHTSA acknowledges the potential ramifications of a recall of this magnitude and does not take its decision lightly. However, the crux of this issue is not a variety of potential (or even attenuated or largely hypothetical) reverberations stemming from a recall—it is that there is defect in the subject inflators that presents an unreasonable risk of death or injury in the event of a crash, and that defect must be addressed.
                </P>
                <P>
                    Every subject inflator that deploys is at risk of rupture, and rupture events are unpredictable and dangerous. Three of the seven field ruptures in the United States occurred between 2009 and 2017, and three more field ruptures occurred in the span of just over four months in 2021. The last field rupture occurred very recently, in 2023. While it is impossible to predict when the next rupture will occur, each inflator that deploys is at risk. NHTSA's statistical evaluation of the future rupture risk, while not imperative to its decision here, reinforces that field ruptures are expected to occur in the future, and any hopes premised simply on the relatively low odds of an inflator rupturing are insufficient to warrant inaction. 
                    <E T="03">Cf. Carburetors,</E>
                     565 F.2d at 759 (“[T]he fact that in past reported cases good luck and swift reactions have prevented many serious injuries does not mean that luck will continue to work in favor of passengers of burning cars. As a matter of statistics their chances may well . . . appear quite favorable. The purpose of the Safety Act, however, is not to protect individuals from the risks associated with defective vehicles only after serious injuries have already occurred; it is to prevent serious injuries stemming from established defects before they occur.”). With each subject inflator that deploys, the vehicle occupants are at risk of severe injury or death from a rupture. That risk is plainly unreasonable under the Safety Act.
                </P>
                <HD SOURCE="HD1">III. Conclusion</HD>
                <P>Every field rupture of the subject inflators in the United States has resulted in at least one vehicle occupant being injured, several have resulted in severe injury, and one has resulted in death. Seven of the subject inflators have already ruptured in vehicles the United States. The facts and circumstances surrounding these U.S. field ruptures, the four foreign field ruptures, and the twenty-three lot acceptance test ruptures underscore the severe impact of the defect on motor vehicle safety. Based on its comprehensive analysis, NHTSA has concluded that the evidence shows that the causes of these ruptures stem from use of a friction welding process without adequate inspection safeguards in place and that all of the subject inflators were produced using this same process. As such, all of the subject inflators have a risk of rupture and are defective. The pattern and evidence of these ruptures confirms that the reactionary, limited-scope recalls are insufficient to address the safety risk and that a recall for the full subject inflator population is necessary. Given the severity of a rupture and the known ruptures there is ample evidence of a defect in the subject inflators. Common sense demands acknowledging that metal shrapnel projecting at high speeds and causing injury or death presents an unreasonable risk to safety, and the Safety Act does not allow for such a risk to remain unaddressed.</P>
                <P>Pursuant to the Safety Act, NHTSA may make a final decision “only after giving the manufacturer[s] an opportunity to present information, views, and arguments showing that there is no defect or noncompliance or that the defect does not affect motor vehicle safety. Any interested person also shall be given an opportunity to present information, views, and arguments.” 49 U.S.C. 30118(b)(1). Given the more extensive detail and discussion of the technical issues in this notice, and to ensure opportunity for additional public feedback, NHTSA is providing an additional 30-day comment period. No additional public meeting will be held.</P>
                <P>
                    If NHTSA makes a final decision that the subject inflators contain a safety defect, NHTSA will order ARC to comply with the obligation to file notice of the safety defect with the agency and will order the vehicle manufacturers to carry out recalls by providing notice and a free remedy. 
                    <E T="03">See id.</E>
                     section 30118(b)(2).
                </P>
                <P>
                    <E T="03">Authority:</E>
                     49 U.S.C. 30118(a), (b); 49 CFR 554.10; delegations of authority at 49 CFR 1.50(a) and 49 CFR 501.8.
                </P>
                <SIG>
                    <NAME>Eileen Sullivan,</NAME>
                    <TITLE>Associate Administrator for Enforcement.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17251 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4910-59-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">DEPARTMENT OF THE TREASURY</AGENCY>
                <SUBAGY>Office of the Comptroller of the Currency</SUBAGY>
                <SUBJECT>Agency Information Collection Activities: Revision of an Approved Information Collection; Submission for OMB Review; Customer Complaint Form</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Office of the Comptroller of the Currency (OCC), Treasury. </P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice and request for comment. </P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The OCC, as part of its continuing effort to reduce paperwork and respondent burden, invites comment on a continuing information collection, as required by the Paperwork Reduction Act of 1995 (PRA). In accordance with the requirements of the PRA, the OCC may not conduct or sponsor, and the respondent is not required to respond to, an information collection unless it displays a currently valid Office of Management and Budget (OMB) control number. The OCC is soliciting comment concerning a revision of its information collection titled, “Customer Complaint Form” The OCC also is giving notice that it has sent the collection to OMB for review.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Comments must be received by September 4, 2024. </P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>Commenters are encouraged to submit comments by email, if possible. You may submit comments by any of the following methods:</P>
                    <P>
                        • 
                        <E T="03">Email: prainfo@occ.treas.gov.</E>
                    </P>
                    <P>
                        • 
                        <E T="03">Mail:</E>
                         Chief Counsel's Office, Attention: Comment Processing, Office of the Comptroller of the Currency, Attention: 1557-0232, 400 7th Street SW, Suite 3E-218, Washington, DC 20219.
                    </P>
                    <P>
                        • 
                        <E T="03">Hand Delivery/Courier:</E>
                         400 7th Street SW, Suite 3E-218, Washington, DC 20219.
                    </P>
                    <P>
                        • 
                        <E T="03">Fax:</E>
                         (571) 293-4835.
                        <PRTPAGE P="63491"/>
                    </P>
                    <P>
                        <E T="03">Instructions:</E>
                         You must include “OCC” as the agency name and “1557-0232” in your comment. In general, the OCC will publish comments on 
                        <E T="03">www.reginfo.gov</E>
                         without change, including any business or personal information provided, such as name and address information, email addresses, or phone numbers. Comments received, including attachments and other supporting materials, are part of the public record and subject to public disclosure. Do not include any information in your comment or supporting materials that you consider confidential or inappropriate for public disclosure.
                    </P>
                    <P>
                        Written comments and recommendations for the proposed information collection should also be sent within 30 days of publication of this notice to 
                        <E T="03">www.reginfo.gov/public/do/PRAMain.</E>
                         You can find this information collection by selecting “Currently under 30-day Review—Open for Public Comments” or by using the search function.
                    </P>
                    <P>You may review comments and other related materials that pertain to this information collection following the close of the 30-day comment period for this notice by the method set forth in the next bullet.</P>
                    <P>
                        • 
                        <E T="03">Viewing Comments Electronically:</E>
                         Go to 
                        <E T="03">www.reginfo.gov.</E>
                         Hover over the “Information Collection Review” tab and click on “Information Collection Review” from the drop-down menu. From the “Currently under Review” drop-down menu, select “Department of Treasury” and then click “submit.” This information collection can be located by searching OMB control number “1557-0232” or “Customer Complaint Form.” Upon finding the appropriate information collection, click on the related “ICR Reference Number.” On the next screen, select “View Supporting Statement and Other Documents” and then click on the link to any comment listed at the bottom of the screen.
                    </P>
                    <P>
                        • For assistance in navigating 
                        <E T="03">www.reginfo.gov,</E>
                         please contact the Regulatory Information Service Center at (202) 482-7340.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Shaquita Merritt, Clearance Officer, (202) 649-5490, Chief Counsel's Office, Office of the Comptroller of the Currency, 400 7th Street SW, Washington, DC 20219. If you are deaf, 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>
                    Under the PRA (44 U.S.C. 3501 
                    <E T="03">et seq.</E>
                    ), Federal agencies must obtain approval from the OMB for each collection of information that they conduct or sponsor. “Collection of information” is defined in 44 U.S.C. 3502(3) and 5 CFR 1320.3(c) to include agency requests or requirements that members of the public submit reports, keep records, or provide information to a third party. The OCC asks the OMB to extend its approval of the collection in this notice.
                </P>
                <P>
                    <E T="03">Title:</E>
                     Customer Complaint Form.
                </P>
                <P>
                    <E T="03">OMB Control No.:</E>
                     1557-0232.
                </P>
                <P>
                    <E T="03">Type of Review:</E>
                     Regular.
                </P>
                <P>
                    <E T="03">Affected Public:</E>
                     Businesses or other for-profit.
                </P>
                <P>
                    <E T="03">Description:</E>
                     The customer complaint form was developed as a courtesy for customers who contact the OCC's Consumer Assistance Group (CAG) and wish to file a formal written complaint. The form offers a template for consumers to use to focus their issues and identify the information necessary to provide a complete picture of their concerns. Use of the form is entirely voluntary; however, use of the form does help avoid the processing delays associated with incomplete complaints and allows CAG to process complaints more efficiently.
                </P>
                <P>CAG uses the information included in a completed form to create a record of the consumer's contact, capture information that can be used to resolve the consumer's issues, and create a database of information that is incorporated into the OCC's supervisory process.</P>
                <P>
                    <E T="03">Estimated Burden:</E>
                </P>
                <P>
                    <E T="03">Estimated Frequency of Response:</E>
                     On occasion.
                </P>
                <P>
                    <E T="03">Estimated Number of Respondents:</E>
                     10,000.
                </P>
                <P>
                    <E T="03">Estimated Total Annual Responses:</E>
                     10,000.
                </P>
                <P>
                    <E T="03">Estimated Total Annual Burden:</E>
                     3,300.
                </P>
                <P>
                    <E T="03">Comments:</E>
                     On May 31, 2024, the OCC published a 60-day notice for this information collection, (89 FR 47237). No comments were received.
                </P>
                <P>Comments continue to be invited on:</P>
                <P>(a) Whether the collection of information is necessary for the proper performance of the functions of the OCC, including whether the information has practical utility;</P>
                <P>(b) The accuracy of the OCC's estimate of the burden of the collection of information;</P>
                <P>(c) Ways to enhance the quality, utility, and clarity of the information to be collected;</P>
                <P>(d) Ways to minimize the burden of the collection on respondents, including through the use of automated collection techniques or other forms of information technology; and</P>
                <P>(e) Estimates of capital or start-up costs and costs of operation, maintenance, and purchase of services to provide information.</P>
                <SIG>
                    <NAME>Eden M. Gray,</NAME>
                    <TITLE>Assistant Director, Office of the Comptroller of the Currency.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17242 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4810-33-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF THE TREASURY</AGENCY>
                <SUBAGY>Office of the Comptroller of the Currency</SUBAGY>
                <SUBJECT>Agency Information Collection Activities: Information Collection Renewal; Submission for OMB Review; Bank Appeals Follow-Up Questionnaire</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Office of the Comptroller of the Currency (OCC), Treasury. </P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice and request for comment. </P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The OCC, as part of its continuing effort to reduce paperwork and respondent burden, invites comment on a continuing information collection, as required by the Paperwork Reduction Act of 1995 (PRA). In accordance with the requirements of the PRA, the OCC may not conduct or sponsor, and the respondent is not required to respond to, an information collection unless it displays a currently valid Office of Management and Budget (OMB) control number. The OCC is soliciting comment concerning the renewal of its information collection titled, “Bank Appeals Follow-Up Questionnaire.” The OCC also is giving notice that it has sent the collection to OMB for review.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Comments must be received by September 4, 2024. </P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>Commenters are encouraged to submit comments by email, if possible. You may submit comments by any of the following methods:</P>
                    <P>
                        • 
                        <E T="03">Email: prainfo@occ.treas.gov.</E>
                    </P>
                    <P>
                        • 
                        <E T="03">Mail:</E>
                         Chief Counsel's Office, Attention: Comment Processing, Office of the Comptroller of the Currency, Attention: 1557-0332, 400 7th Street SW, Suite 3E-218, Washington, DC 20219.
                    </P>
                    <P>
                        • 
                        <E T="03">Hand Delivery/Courier:</E>
                         400 7th Street SW, Suite 3E-218, Washington, DC 20219.
                    </P>
                    <P>
                        • 
                        <E T="03">Fax:</E>
                         (571) 293-4835.
                    </P>
                    <P>
                        <E T="03">Instructions:</E>
                         You must include “OCC” as the agency name and “1557-0332” in your comment. In general, the OCC will publish comments on 
                        <E T="03">www.reginfo.gov</E>
                         without change, including any business or personal information provided, such as name and address information, email addresses, or phone numbers. Comments received, 
                        <PRTPAGE P="63492"/>
                        including attachments and other supporting materials, are part of the public record and subject to public disclosure. Do not include any information in your comment or supporting materials that you consider confidential or inappropriate for public disclosure.
                    </P>
                    <P>
                        Written comments and recommendations for the proposed information collection should also be sent within 30 days of publication of this notice to 
                        <E T="03">www.reginfo.gov/public/do/PRAMain.</E>
                         You can find this information collection by selecting “Currently under 30-day Review—Open for Public Comments” or by using the search function.
                    </P>
                    <P>You may review comments and other related materials that pertain to this information collection following the close of the 30-day comment period for this notice by the method set forth in the next bullet.</P>
                    <P>
                        • 
                        <E T="03">Viewing Comments Electronically:</E>
                         Go to 
                        <E T="03">www.reginfo.gov.</E>
                         Hover over the “Information Collection Review” tab and click on “Information Collection Review” from the drop-down menu. From the “Currently under Review” drop-down menu, select “Department of Treasury” and then click “submit.” This information collection can be located by searching OMB control number “1557-0332” or “Bank Appeals Follow-Up Questionnaire.” Upon finding the appropriate information collection, click on the related “ICR Reference Number.” On the next screen, select “View Supporting Statement and Other Documents” and then click on the link to any comment listed at the bottom of the screen.
                    </P>
                    <P>
                        • For assistance in navigating 
                        <E T="03">www.reginfo.gov,</E>
                         please contact the Regulatory Information Service Center at (202) 482-7340.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Shaquita Merritt, Clearance Officer, (202) 649-5490, Chief Counsel's Office, Office of the Comptroller of the Currency, 400 7th Street SW, Washington, DC 20219. If you are deaf, 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>
                    Under the PRA (44 U.S.C. 3501 
                    <E T="03">et seq.</E>
                    ), Federal agencies must obtain approval from the OMB for each collection of information that they conduct or sponsor. “Collection of information” is defined in 44 U.S.C. 3502(3) and 5 CFR 1320.3(c) to include agency requests or requirements that members of the public submit reports, keep records, or provide information to a third party. The OCC asks the OMB to extend its approval of the collection in this notice.
                </P>
                <P>
                    <E T="03">Title:</E>
                     Bank Appeals Follow-Up Questionnaire.
                </P>
                <P>
                    <E T="03">OMB Control No.:</E>
                     1557-0332.
                </P>
                <P>
                    <E T="03">Type of Review:</E>
                     Regular.
                </P>
                <P>
                    <E T="03">Affected Public:</E>
                     Businesses or other for-profit.
                </P>
                <P>
                    <E T="03">Description:</E>
                     The OCC's Office of the Ombudsman (Ombudsman) is committed to assessing its efforts to provide a fair and expeditious appeal process to institutions under OCC supervision. To perform this assessment, it is necessary to obtain feedback from individual appellant institutions on the effectiveness of the Ombudsman's efforts to provide a fair and expeditious appeals process and suggestions on ways to enhance the bank appeals process. For each Bank Appeals Follow-Up Questionnaire submitted, the Ombudsman uses the information gathered to assess the OCC's adherence to OCC Bulletin 2013-15, “Bank Appeals Process,” dated June 7, 2013, and to enhance its bank appeals program.
                </P>
                <P>
                    <E T="03">Estimated Burden:</E>
                </P>
                <P>
                    <E T="03">Estimated Frequency of Response:</E>
                     On occasion.
                </P>
                <P>
                    <E T="03">Estimated Number of Respondents:</E>
                     5.
                </P>
                <P>
                    <E T="03">Estimated Total Annual Burden:</E>
                     0.85 hours.
                    <SU>1</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         The 60-Day FRN erroneously published the Estimated Total Annual Burden as 85 hours. The burden number should have been published as 0.85 hours.
                    </P>
                </FTNT>
                <P>
                    <E T="03">Comments:</E>
                     On May 31, 2024, the OCC published a 60-day notice for this information collection, (89 FR 47236). No comments were received.
                </P>
                <P>Comments continue to be invited on:</P>
                <P>(a) Whether the collection of information is necessary for the proper performance of the functions of the OCC, including whether the information has practical utility;</P>
                <P>(b) The accuracy of the OCC's estimate of the burden of the collection of information;</P>
                <P>(c) Ways to enhance the quality, utility, and clarity of the information to be collected;</P>
                <P>(d) Ways to minimize the burden of the collection on respondents, including through the use of automated collection techniques or other forms of information technology; and</P>
                <P>(e) Estimates of capital or start-up costs and costs of operation, maintenance, and purchase of services to provide information.</P>
                <SIG>
                    <NAME>Eden M. Gray,</NAME>
                    <TITLE>Assistant Director, Office of the Comptroller of the Currency.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17244 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4810-33-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF THE TREASURY</AGENCY>
                <SUBAGY>Office of the Comptroller of the Currency</SUBAGY>
                <SUBJECT>Agency Information Collection Activities: Information Collection Renewal; Submission for OMB Review; Registration of Mortgage Loan Originators</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Office of the Comptroller of the Currency (OCC), Treasury.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice and request for comment.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The OCC, as part of its continuing effort to reduce paperwork and respondent burden, invites comment on a continuing information collection, as required by the Paperwork Reduction Act of 1995 (PRA). In accordance with the requirements of the PRA, the OCC may not conduct or sponsor, and the respondent is not required to respond to, an information collection unless it displays a currently valid Office of Management and Budget (OMB) control number. The OCC is soliciting comment concerning the revision to its information collection titled, “Registration of Mortgage Loan Originators.” The OCC also is giving notice that it has sent the collection to OMB for review.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Comments must be received by September 4, 2024.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>Commenters are encouraged to submit comments by email, if possible. You may submit comments by any of the following methods:</P>
                    <P>
                        • 
                        <E T="03">Email: prainfo@occ.treas.gov.</E>
                    </P>
                    <P>
                        • 
                        <E T="03">Mail:</E>
                         Chief Counsel's Office, Attention: Comment Processing, Office of the Comptroller of the Currency, Attention: 1557-0243, 400 7th Street SW, Suite 3E-218, Washington, DC 20219.
                    </P>
                    <P>
                        • 
                        <E T="03">Hand Delivery/Courier:</E>
                         400 7th Street SW, Suite 3E-218, Washington, DC 20219.
                    </P>
                    <P>
                        • 
                        <E T="03">Fax:</E>
                         (571) 293-4835.
                    </P>
                    <P>
                        <E T="03">Instructions:</E>
                         You must include “OCC” as the agency name and “1557-0243” in your comment. In general, the OCC will publish comments on 
                        <E T="03">www.reginfo.gov</E>
                         without change, including any business or personal information provided, such as name and address information, email addresses, or phone numbers. Comments received, including attachments and other supporting materials, are part of the public record and subject to public disclosure. Do not include any information in your comment or supporting materials that you consider confidential or inappropriate for public disclosure.
                    </P>
                    <P>
                        Written comments and recommendations for the proposed 
                        <PRTPAGE P="63493"/>
                        information collection should also be sent within 30 days of publication of this notice to 
                        <E T="03">www.reginfo.gov/public/do/PRAMain.</E>
                         You can find this information collection by selecting “Currently under 30-day Review—Open for Public Comments” or by using the search function.
                    </P>
                    <P>You may review comments and other related materials that pertain to this information collection following the close of the 30-day comment period for this notice by the method set forth in the next bullet.</P>
                    <P>
                        • 
                        <E T="03">Viewing Comments Electronically:</E>
                         Go to 
                        <E T="03">www.reginfo.gov.</E>
                         Hover over the “Information Collection Review” tab and click on “Information Collection Review” from the drop-down menu. From the “Currently under Review” drop-down menu, select “Department of Treasury” and then click “submit.” This information collection can be located by searching OMB control number “1557-0243” or “Registration of Mortgage Loan Originators.” Upon finding the appropriate information collection, click on the related “ICR Reference Number.” On the next screen, select “View Supporting Statement and Other Documents” and then click on the link to any comment listed at the bottom of the screen.
                    </P>
                    <P>
                        • For assistance in navigating 
                        <E T="03">www.reginfo.gov,</E>
                         please contact the Regulatory Information Service Center at (202) 482-7340.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Shaquita Merritt, Clearance Officer, (202) 649-5490, Chief Counsel's Office, Office of the Comptroller of the Currency, 400 7th Street SW, Washington, DC 20219. If you are deaf, 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>
                    Under the PRA (44 U.S.C. 3501 
                    <E T="03">et seq.</E>
                    ), Federal agencies must obtain approval from the OMB for each collection of information that they conduct or sponsor. “Collection of information” is defined in 44 U.S.C. 3502(3) and 5 CFR 1320.3(c) to include agency requests or requirements that members of the public submit reports, keep records, or provide information to a third party. The OCC asks the OMB to extend its approval of the collection in this notice.
                </P>
                <P>
                    <E T="03">Title:</E>
                     Registration of Mortgage Loan Originators.
                </P>
                <P>
                    <E T="03">OMB Control No.:</E>
                     1557-0243.
                </P>
                <P>
                    <E T="03">Description:</E>
                     The Secure and Fair Enforcement for Mortgage Licensing Act (the S.A.F.E. Act or Act) 
                    <SU>1</SU>
                    <FTREF/>
                     requires an employee of a Federally-regulated bank, savings association, credit union, or farm credit institution and their subsidiaries (collectively, institutions) who engages in the business of a residential mortgage loan originator (MLO) and does not qualify for the 
                    <E T="03">de minimis</E>
                     exception to register with the Nationwide Mortgage Licensing System and Registry (Registry) and obtain a unique identifier. Further, the S.A.F.E. Act provides that institutions must require their employees who act as MLOs to comply with the Act's registration requirements and obtain a unique identifier. Institutions must also adopt and follow written policies and procedures to ensure compliance with these requirements.
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         The S.A.F.E. Act was enacted as part of the Housing and Economic Recovery Act of 2008, Public Law 110-289, Division A, Title V, sections 1501-1517, 122 Stat. 2654, 2810-2824 (July 30, 2008), 
                        <E T="03">codified at</E>
                         12 U.S.C. 5101-5116.
                    </P>
                </FTNT>
                <P>Among other things, the Registry is intended to aggregate and improve the flow of information to and between regulators; provide increased accountability and tracking of mortgage loan originators; enhance consumer protections; reduce fraud in the residential mortgage loan origination process; and provide consumers with easily accessible information at no charge regarding the employment history of, and the publicly adjudicated disciplinary and enforcement actions against, MLOs.</P>
                <P>
                    Along with the Board of Governors of the Federal Reserve System, the Federal Deposit Insurance Corporation, the National Credit Union Administration, and the Farm Credit Administration, the OCC issued a final rule implementing the S.A.F.E. Act.
                    <SU>2</SU>
                    <FTREF/>
                     The Dodd-Frank Wall Street Reform and Consumer Protection Act (Dodd-Frank Act), Public Law 111-203, later provided for the transfer of this rule to the Consumer Financial Protection Bureau (CFPB), and the CFPB republished this rule as 12 CFR part 1007.
                    <SU>3</SU>
                    <FTREF/>
                     However, the OCC retains enforcement authority for national banks, Federal savings associations, and Federal branches and agencies of foreign banks with total assets of $10 billion or less.
                    <SU>4</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>2</SU>
                         75 FR 44656 (July 28, 2010), as corrected in 75 FR 51623 (Aug. 23, 2010).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>3</SU>
                         76 FR 78483 (Dec. 19, 2011).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>4</SU>
                         
                        <E T="03">See</E>
                         section 1025 of the Dodd-Frank Act, codified at 12 U.S.C. 5515.
                    </P>
                </FTNT>
                <HD SOURCE="HD1">MLO Reporting Requirements</HD>
                <P>Except in situations where the de minimis exception applies, 12 CFR 1007.103 requires an employee of an institution who acts as an MLO to register with the Registry, obtain a unique identifier, and maintain and update such registration. This section also requires institutions to require their MLO employees to comply with these requirements. Section 1007.103(d) sets forth the categories of information that an institution must require each MLO employee to submit to the Registry or submit on the employee's behalf. This section also requires each MLO employee to submit to the Registry an attestation as to the correctness of the information submitted and an authorization for the Registry and the employing institution to obtain certain additional information related to the employee.</P>
                <HD SOURCE="HD1">MLO Disclosure Requirement</HD>
                <P>Section 1007.105(b) requires MLOs to provide their unique identifier to a consumer upon request, before acting as an MLO, and through the originator's initial written communication with a consumer, if any, whether on paper or electronically.</P>
                <HD SOURCE="HD1">Financial Institution Reporting Requirements</HD>
                <P>Section 1007.103(e) specifies the institution-related and employee information an institution must submit to the Registry in connection with the initial registration of one or more MLOs and annually thereafter. The institution also must update this information within 30 days of the date that this information becomes inaccurate. Employees of the institution who submit information to the Registry on behalf of the institution must verify their identity and attest that they have the authority to enter data on behalf of the institution, that the information submitted is correct, and that the covered financial institution will keep the required information current and will file accurate supplementary information on a timely basis.</P>
                <HD SOURCE="HD1">Financial Institution Disclosure Requirements</HD>
                <P>Section 1007.105(a) requires the institution to make the unique identifiers of its MLO employees available to consumers in a manner and method practicable to the institution.</P>
                <HD SOURCE="HD1">Financial Institution Recordkeeping Requirements</HD>
                <P>
                    Section 1007.104 requires that an institution that employs one or more MLOs to adopt and follow written policies and procedures to, at a minimum, address certain specified areas related to MLO registration. These policies must be appropriate to the nature, size and complexity of the institution's mortgage lending activities and apply only to those employees acting within the scope of their employment at the institution.
                    <PRTPAGE P="63494"/>
                </P>
                <P>
                    <E T="03">Type of Review:</E>
                     Regular.
                </P>
                <P>
                    <E T="03">Affected Public:</E>
                     Businesses or other for-profit.
                </P>
                <P>
                    <E T="03">Estimated Frequency of Response:</E>
                     On occasion.
                </P>
                <P>
                    <E T="03">Estimated Number of Respondents:</E>
                     90,574.
                </P>
                <P>
                    <E T="03">Estimated Total Annual Burden:</E>
                     40,671 hours.
                </P>
                <P>
                    <E T="03">Comments:</E>
                     On May 28, 2024, the OCC published a 60-day notice for this information collection, (89 FR 46303). No comments were received.
                </P>
                <P>Comments continue to be invited on:</P>
                <P>(a) Whether the collection of information is necessary for the proper performance of the functions of the OCC, including whether the information has practical utility;</P>
                <P>(b) The accuracy of the OCC's estimate of the burden of the collection of information;</P>
                <P>(c) Ways to enhance the quality, utility, and clarity of the information to be collected;</P>
                <P>(d) Ways to minimize the burden of the collection on respondents, including through the use of automated collection techniques or other forms of information technology; and</P>
                <P>(e) Estimates of capital or start-up costs and costs of operation, maintenance, and purchase of services to provide information.</P>
                <SIG>
                    <NAME>Eden M. Gray,</NAME>
                    <TITLE>Assistant Director, Office of the Comptroller of the Currency.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17147 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4810-33-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">DEPARTMENT OF VETERANS AFFAIRS</AGENCY>
                <DEPDOC>[OMB Control No. 2900-0760]</DEPDOC>
                <SUBJECT>Agency Information Collection Activity Under OMB Review: Paralympics &amp; Olympics Monthly Training Allowance Application and Certification</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Veterans Health Administration, Department of Veterans Affairs.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>In compliance with the Paperwork Reduction Act (PRA) of 1995, this notice announces that the Veterans Health Administration (VHA), Department of Veterans Affairs, will submit the collection of information abstracted below to the Office of Management and Budget (OMB) for review and comment. The PRA submission describes the nature of the information collection and its expected cost and burden, and it includes the actual data collection instrument.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>
                        Comments and recommendations for the proposed information collection should be sent within 30 days of publication of this notice by clicking on the following link 
                        <E T="03">www.reginfo.gov/public/do/PRAMain,</E>
                         select “Currently under Review—Open for Public Comments”, then search the list for the information collection by Title or “OMB Control No. 2900-0760.”
                    </P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P/>
                    <P>
                        <E T="03">Program-specific information:</E>
                         Veta Brooks-Berryman, 202-480-4633, 
                        <E T="03">Veta.Brooks1@va.gov.</E>
                    </P>
                    <P>
                        <E T="03">VA PRA information:</E>
                         Maribel Aponte, 202-461-8900, 
                        <E T="03">vacopaperworkreduact@va.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P/>
                <P>
                    <E T="03">Title:</E>
                     Paralympics &amp; Olympics Monthly Training Allowance Application and Certification (VA Forms 0918a &amp; 0918b).
                </P>
                <P>
                    <E T="03">OMB Control Number:</E>
                     2900-0760. 
                    <E T="03">https://www.reginfo.gov/public/do/PRASearch.</E>
                </P>
                <P>
                    <E T="03">Type of Review:</E>
                     Revision of a currently approved collection.
                </P>
                <P>
                    <E T="03">Abstract:</E>
                     Section 703 of the Veterans' Benefits Improvement Act of 2008, Public Law 110-389, authorizes the Department of Veterans Affairs (VA) to administer a monthly assistance allowance to a veteran with a service-connected or non-service-connected disability if the veteran is competing for a slot on or selected for the United States Paralympics and Olympics team or is residing at a United States Paralympics or Olympics training center. The Office of National Veterans Sports Programs and Special Events will use VA Forms 0918a and 0918b to collect information to certify eligibility for the monthly assistance allowance, verify the veteran's mailing address, confirm that he or she has been accepted by the Paralympics or Olympics to compete in a specific Paralympic or Olympic sport, and to determine their marital status and number of dependents for the purpose of assessing payment amounts.
                </P>
                <P>
                    An agency may not conduct or sponsor, and a person is not required to respond to a collection of information unless it displays a currently valid OMB control number. The 
                    <E T="04">Federal Register</E>
                     Notice with a 60-day comment period soliciting comments on this collection of information was published at 89 FR 46993, May 30, 2024.
                </P>
                <P>
                    <E T="03">Affected Public:</E>
                     Individuals or Households.
                </P>
                <P>
                    <E T="03">Estimated Annual Burden:</E>
                     43 hours.
                </P>
                <P>
                    <E T="03">Estimated Average Burden per Respondent:</E>
                     15 minutes.
                </P>
                <P>
                    <E T="03">Frequency of Response:</E>
                     Once annually.
                </P>
                <P>
                    <E T="03">Estimated Number of Respondents:</E>
                     170.
                </P>
                <P>
                    <E T="03">Authority:</E>
                     44 U.S.C. 3501 
                    <E T="03">et seq.</E>
                </P>
                <SIG>
                    <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-17215 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 8320-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF VETERANS AFFAIRS</AGENCY>
                <SUBJECT>Solicitation of Nominations for Appointment to the Geriatrics and Gerontology Advisory Committee</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Department of Veterans Affairs.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of Geriatrics and Gerontology Advisory Committee appointment.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Department of Veterans Affairs (VA), Office of Geriatrics and Extended Care, is seeking nominations of qualified candidates to be considered for appointment as a member of the Geriatrics and Gerontology Advisory Committee (herein-after in this section referred to as “the Committee”). The Committee advises the VA Secretary and the Under Secretary for Health on all matters pertaining to geriatrics and gerontology. This solicitation is targeted to those with expertise related to the Geriatric Research, Education, and Clinical Center (GRECC) program.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Nominations of qualified candidates are being sought to fill vacancies on the Committee. Nominations for membership on the Committee must be received no later than 5 p.m. eastern time on September 13th, 2024.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        All nominations should be emailed to Marianne Shaughnessy, Ph.D., AGPCNP-BC, GS-C, FAAN, at 
                        <E T="03">Marianne.Shaughnessy@va.gov.</E>
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Marianne Shaughnessy, Ph.D., AGPCNP-BC, GS-C, FAAN, at 202-407-6798 or at 
                        <E T="03">Marianne.Shaughnessy@va.gov.</E>
                         A copy of the Committee charter and list of the current membership can also be obtained by contacting Dr. Shaughnessy.
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    The Committee's areas of interest include but are not limited to: (1) assessing the capability of VA health care facilities to respond with the most effective and appropriate services possible to the medical, psychological and social needs of Veterans facing the consequences of aging, serious illness or disability; and (2) advancing scientific knowledge to meet those needs by enhancing geriatric 
                    <PRTPAGE P="63495"/>
                    care for older Veterans through geriatric and gerontology research, the training of health personnel in the provision of health care to older individuals, and the development of improved models of clinical services for older Veterans.
                </P>
                <P>
                    <E T="03">Membership Criteria and Qualifications:</E>
                     The Committee is comprised of 12 members in addition to ex officio members, each of whom have established interest and considerable vocation-related experiences bearing on health care for aging Veterans, including experience in areas such as: VA and non-VA health systems, academic geriatric and gerontology programs, palliative medicine, home and community-based care, nursing home care, relevant policy issues, and grant-funded academic research.
                </P>
                <P>The expertise required of GGAC members includes, but is not limited to, the following:</P>
                <P>a. familiarity or experience with clinical and health policies concerning the elderly; and/or</P>
                <P>b. familiarity or experience with the partnerships between VA and health sciences academic programs; and/or</P>
                <P>c. familiarity with the history of geriatrics in the VA and in the US, and the unique role that has been played in that evolution by the VA's GRECCs.</P>
                <P>
                    <E T="03">Membership Requirements:</E>
                     The Committee holds at least one face to face meeting in Washington, DC and conducts 4-5 site visits a year. The ideal candidate will be willing to travel 3-5 times per year to help the Committee fulfill its Chartered objectives.
                </P>
                <P>The Committee's diverse membership is characterized by a range of backgrounds and knowledge sufficiently broad to provide adequate advice and guidance to the Secretary. VA strives to develop a Committee membership that includes diversity in military services, ranks, and deployments, working with Veterans, committee subject matter expertise, as well as diversity in race/ethnicity, gender, religion, disability, geographical background, and profession. We ask that nominations include information of this type so that VA can ensure diverse Committee membership.</P>
                <P>
                    <E T="03">Requirements for Nomination Submission:</E>
                     Nominations should be typed (one nomination per nominator). Self-nominations are acceptable. Nomination package should include:
                </P>
                <P>
                    (1) A letter of nomination that clearly states the name and affiliation of the nominee, the basis for the nomination (
                    <E T="03">i.e.,</E>
                     specific attributes which qualify the nominee for service in this capacity), and a statement from the nominee indicating the willingness to serve as a member of the Committee and a statement confirming that he/she is not a federally-registered lobbyist. Nominations must state that the nominee appears to have no conflict of interest that would preclude membership.
                </P>
                <P>(2) The nominee's contact information, including name, mailing address, telephone numbers, and email address;</P>
                <P>(3) The nominee's curriculum vitae;</P>
                <P>(4) Letters of recommendation are accepted, but not required; and</P>
                <P>(5) This solicitation is targeted to those with expertise related to the GRECC program.</P>
                <P>Individuals selected for appointment to the Committee shall be invited to serve a four-year term. Committee members will receive a stipend for attending Committee meetings, including per diem and reimbursement for travel expenses incurred. Applicants who are qualified but not selected will be asked for permission to recall if their expertise is needed in the future.</P>
                <P>The Department makes every effort to ensure that the membership of VA Federal advisory committees is diverse in terms of points of view represented and the committee's capabilities. Appointments to this Committee shall be made without discrimination because of a person's race, color, religion, sex, sexual orientation, gender identity, national origin, age, disability, or genetic information.</P>
                <SIG>
                    <DATED>Dated: July 31, 2024.</DATED>
                    <NAME>LaTonya L. Small,</NAME>
                    <TITLE>Federal Advisory Committee Management Officer.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2024-17214 Filed 8-2-24; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 8320-01-P</BILCOD>
        </NOTICE>
    </NOTICES>
    <VOL>89</VOL>
    <NO>150</NO>
    <DATE>Monday, August 5, 2024</DATE>
    <UNITNAME>Proposed Rules</UNITNAME>
    <NEWPART>
        <PTITLE>
            <PRTPAGE P="63497"/>
            <PARTNO>Part II</PARTNO>
            <AGENCY TYPE="P">Department of Health and Human Services</AGENCY>
            <CFR>45 CFR Parts 170, 171, and 172</CFR>
            <TITLE>Health Data, Technology, and Interoperability: Patient Engagement, Information Sharing, and Public Health Interoperability; Proposed Rule</TITLE>
        </PTITLE>
        <PRORULES>
            <PRORULE>
                <PREAMB>
                    <PRTPAGE P="63498"/>
                    <AGENCY TYPE="S">DEPARTMENT OF HEALTH AND HUMAN SERVICES</AGENCY>
                    <SUBAGY>Office of the Secretary</SUBAGY>
                    <CFR>45 CFR Parts 170, 171, and 172</CFR>
                    <RIN>RIN 0955-AA06</RIN>
                    <SUBJECT>Health Data, Technology, and Interoperability: Patient Engagement, Information Sharing, and Public Health Interoperability</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>Proposed rule.</P>
                    </ACT>
                    <SUM>
                        <HD SOURCE="HED">SUMMARY:</HD>
                        <P>This proposed rule seeks to advance interoperability, improve transparency, and support the access, exchange, and use of electronic health information through proposals for: standards adoption; adoption of certification criteria to advance public health data exchange; expanded uses of certified application programming interfaces, such as for electronic prior authorization, patient access, care management, and care coordination; and information sharing under the information blocking regulations. It proposes to establish a new baseline version of the United States Core Data for Interoperability. The proposed rule would update the ONC Health IT Certification Program to enhance interoperability and optimize certification processes to reduce burden and costs. The proposed rule would also implement certain provisions related to the Trusted Exchange Framework and Common Agreement (TEFCA), which would support the reliability, privacy, security, and trust within TEFCA.</P>
                    </SUM>
                    <DATES>
                        <HD SOURCE="HED">DATES:</HD>
                        <P>To be assured consideration, written or electronic comments must be received at one of the addresses provided below, no later than 5 p.m. Eastern Time on October 4, 2024.</P>
                    </DATES>
                    <ADD>
                        <HD SOURCE="HED">ADDRESSES:</HD>
                        <P>You may submit comments, identified by RIN 0955-AA06, by any of the following methods (please do not submit duplicate comments). Because of staff and resource limitations, we cannot accept comments by facsimile (FAX) transmission.</P>
                        <P>
                            • 
                            <E T="03">Federal eRulemaking Portal:</E>
                             Follow the instructions for submitting comments. Attachments should be in Microsoft Word, Microsoft Excel, or Adobe PDF; however, we prefer Microsoft Word. 
                            <E T="03">http://www.regulations.gov.</E>
                        </P>
                        <P>
                            • 
                            <E T="03">Regular, Express, or Overnight Mail:</E>
                             Department of Health and Human Services, Office of the National Coordinator for Health Information Technology, Attention: Health Data, Technology, and Interoperability: Patient Engagement, Information Sharing, and Public Health Interoperability Proposed Rule, Mary E. Switzer Building, Mail Stop: 7033A, 330 C Street SW, Washington, DC 20201. Please submit one original and two copies.
                        </P>
                        <P>
                            • 
                            <E T="03">Hand Delivery or Courier:</E>
                             Office of the National Coordinator for Health Information Technology, Attention: Health Data, Technology, and Interoperability: Patient Engagement, Information Sharing, and Public Health Interoperability Proposed Rule, Mary E. Switzer Building, Mail Stop: 7033A, 330 C Street SW, Washington, DC 20201. Please submit one original and two copies. (Because access to the interior of the Mary E. Switzer Building is not readily available to persons without Federal government identification, commenters are encouraged to leave their comments in the mail drop slots located in the main lobby of the building.)
                        </P>
                        <P>
                            <E T="03">Inspection of Public Comments:</E>
                             All comments received before the close of the comment period will be available for public inspection, including any personally identifiable or confidential business information that is included in a comment. Please do not include anything in your comment submission that you do not wish to share with the general public. Such information includes, but is not limited to, the following: a person's social security number; date of birth; driver's license number; state identification number or foreign country equivalent; passport number; financial account number; credit or debit card number; any personal health information; or any business information that could be considered proprietary. We will post all comments that are received before the close of the comment period at 
                            <E T="03">http://www.regulations.gov.</E>
                        </P>
                        <P>
                            <E T="03">Docket:</E>
                             For access to the docket to read background documents, comments received, or the plain-language summary of the proposed rule of not more than 100 words in length required by the Providing Accountability Through Transparency Act of 2023, go to 
                            <E T="03">http://www.regulations.gov</E>
                             or the Department of Health and Human Services, Office of the National Coordinator for Health Information Technology, Mary E. Switzer Building, Mail Stop: 7033A, 330 C Street SW, Washington, DC 20201 (call ahead to the contact listed below to arrange for inspection).
                        </P>
                    </ADD>
                    <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>
                    <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">B. Summary of Major Provisions</FP>
                        <FP SOURCE="FP1-2">1. ONC Health IT Certification Program Updates</FP>
                        <FP SOURCE="FP1-2">a. New and Revised Standards and Certification Criteria</FP>
                        <FP SOURCE="FP1-2">i. The United States Core Data for Interoperability Version 4 (USCDI v4)</FP>
                        <FP SOURCE="FP1-2">ii. SMART App Launch 2.2</FP>
                        <FP SOURCE="FP1-2">iii. User-Access Brands and Endpoints</FP>
                        <FP SOURCE="FP1-2">iv. Standards for Encryption and Decryption of Electronic Health Information</FP>
                        <FP SOURCE="FP1-2">v. Minimum Standards Code Sets Updates</FP>
                        <FP SOURCE="FP1-2">vi. New Imaging Requirements for Health IT Modules</FP>
                        <FP SOURCE="FP1-2">vii. Revised Clinical Information Reconciliation and Incorporation Criterion</FP>
                        <FP SOURCE="FP1-2">viii. Revised Electronic Prescribing Certification Criterion</FP>
                        <FP SOURCE="FP1-2">ix. New Real-Time Prescription Benefit Criterion</FP>
                        <FP SOURCE="FP1-2">x. Electronic Health Information (EHI) Export—Single Patient EHI Export Exemption</FP>
                        <FP SOURCE="FP1-2">xi. Revised End-User Device Encryption Criterion</FP>
                        <FP SOURCE="FP1-2">xii. Revised Criterion for Encrypt Authentication Credentials</FP>
                        <FP SOURCE="FP1-2">xiii. Health IT Modules Supporting Public Health Data Exchange</FP>
                        <FP SOURCE="FP1-2">xiv. Bulk Data Enhancements</FP>
                        <FP SOURCE="FP1-2">xv. New Requirements to Support Dynamic Client Registration Protocol in the Program</FP>
                        <FP SOURCE="FP1-2">xvi. New Certification Criteria for Modular API Capabilities</FP>
                        <FP SOURCE="FP1-2">xvii. Multi-factor Authentication Criterion</FP>
                        <FP SOURCE="FP1-2">xviii. Revised Computerized Provider Order Entry—Laboratory Criterion</FP>
                        <FP SOURCE="FP1-2">xix. Revised Standardized API for Patient and Population Services Criterion to Align with Modular API Capabilities</FP>
                        <FP SOURCE="FP1-2">xx. Patient, Provider, and Payer APIs</FP>
                        <FP SOURCE="FP1-2">2. Conditions and Maintenance of Certification Requirements—Insights and Attestations</FP>
                        <FP SOURCE="FP1-2">a. Insights Condition and Maintenance of Certification Requirements</FP>
                        <FP SOURCE="FP1-2">b. Attestations Condition and Maintenance of Certification Requirements</FP>
                        <FP SOURCE="FP1-2">3. Administrative Updates</FP>
                        <FP SOURCE="FP1-2">4. Correction—Privacy and Security Certification Framework</FP>
                        <FP SOURCE="FP1-2">5. Information Blocking Enhancements</FP>
                        <FP SOURCE="FP1-2">
                            6. Trusted Exchange Framework and Common Agreement
                            <E T="51">TM</E>
                        </FP>
                        <FP SOURCE="FP1-2">
                            <E T="03">C. Severability</E>
                        </FP>
                        <FP SOURCE="FP1-2">
                            <E T="03">D. Costs and Benefits</E>
                        </FP>
                        <FP SOURCE="FP-2">II. Background</FP>
                        <FP SOURCE="FP1-2">
                            <E T="03">A. Statutory Basis</E>
                        </FP>
                        <FP SOURCE="FP1-2">1. Standards, Implementation Specifications, and Certification Criteria</FP>
                        <FP SOURCE="FP1-2">
                            2. ONC Health IT Certification Program Rules
                            <PRTPAGE P="63499"/>
                        </FP>
                        <FP SOURCE="FP1-2">
                            <E T="03">B. Regulatory History</E>
                        </FP>
                        <FP SOURCE="FP-2">III. ONC Health IT Certification Program Updates</FP>
                        <FP SOURCE="FP1-2">
                            <E T="03">A. Standards and Implementations Specifications</E>
                        </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">
                            <E T="03">B. New and Revised Standards and Certification Criteria</E>
                        </FP>
                        <FP SOURCE="FP1-2">1. The United States Core Data for Interoperability Version 4 (USCDI v4)</FP>
                        <FP SOURCE="FP1-2">a. Background and USCDI v4 Update</FP>
                        <FP SOURCE="FP1-2">b. Certification Criteria that Reference USCDI</FP>
                        <FP SOURCE="FP1-2">2. SMART App Launch 2.2</FP>
                        <FP SOURCE="FP1-2">3. User-Access Brands and Endpoints</FP>
                        <FP SOURCE="FP1-2">4. Standards for Encryption and Decryption of Electronic Health Information</FP>
                        <FP SOURCE="FP1-2">a. Background</FP>
                        <FP SOURCE="FP1-2">b. Proposal</FP>
                        <FP SOURCE="FP1-2">5. Minimum Standards Code Sets Updates</FP>
                        <FP SOURCE="FP1-2">6. New Imaging Requirements for Health IT Modules</FP>
                        <FP SOURCE="FP1-2">7. Revised Clinical Information Reconciliation and Incorporation Criterion</FP>
                        <FP SOURCE="FP1-2">8. Revised Electronic Prescribing Certification Criterion</FP>
                        <FP SOURCE="FP1-2">a. Electronic Prescribing Standard</FP>
                        <FP SOURCE="FP1-2">b. Proposed Transactions c. Additional Proposals</FP>
                        <FP SOURCE="FP1-2">9. New Real-Time Prescription Benefit Criterion</FP>
                        <FP SOURCE="FP1-2">a. Background</FP>
                        <FP SOURCE="FP1-2">b. Revision to the Base EHR Definition and Health IT Module Dependent Criteria Requirements</FP>
                        <FP SOURCE="FP1-2">c. Real-Time Prescription Benefit Standard</FP>
                        <FP SOURCE="FP1-2">d. Sending and Receiving Real-Time Prescription Benefit Information</FP>
                        <FP SOURCE="FP1-2">e. Additional Topics</FP>
                        <FP SOURCE="FP1-2">10. Electronic Health Information (EHI) Export—Single Patient EHI Export Exemption</FP>
                        <FP SOURCE="FP1-2">a. Background</FP>
                        <FP SOURCE="FP1-2">b. Proposal for EHI Export</FP>
                        <FP SOURCE="FP1-2">c. Proposal for Associated Assurances Requirements for Single Patient EHI Export Exemption</FP>
                        <FP SOURCE="FP1-2">11. Revised End-User Device Encryption Criterion</FP>
                        <FP SOURCE="FP1-2">a. Background</FP>
                        <FP SOURCE="FP1-2">b. Proposal</FP>
                        <FP SOURCE="FP1-2">12. Revised Criterion for Encrypt Authentication Credentials</FP>
                        <FP SOURCE="FP1-2">a. Background</FP>
                        <FP SOURCE="FP1-2">b. Proposal</FP>
                        <FP SOURCE="FP1-2">13. Health IT Modules Supporting Public Health Data Exchange</FP>
                        <FP SOURCE="FP1-2">a. Background</FP>
                        <FP SOURCE="FP1-2">b. Regulatory History</FP>
                        <FP SOURCE="FP1-2">c. Proposal Overview</FP>
                        <FP SOURCE="FP1-2">d. Revised Certification Criteria for Health IT Modules Supporting Public Health Data Exchange</FP>
                        <FP SOURCE="FP1-2">e. New Certification Criteria for Health IT Modules Supporting Public Health Data Exchange</FP>
                        <FP SOURCE="FP1-2">f. New Standardized API for Public Health Data Exchange</FP>
                        <FP SOURCE="FP1-2">14. Bulk Data Enhancements</FP>
                        <FP SOURCE="FP1-2">a. Background</FP>
                        <FP SOURCE="FP1-2">b. Proposal</FP>
                        <FP SOURCE="FP1-2">15. New Requirements to Support Dynamic Client Registration Protocol in the Program</FP>
                        <FP SOURCE="FP1-2">a. Background to Dynamic Client Registration</FP>
                        <FP SOURCE="FP1-2">b. Adoption of HL7 UDAP Security IG v1</FP>
                        <FP SOURCE="FP1-2">c. Revision of Standardized API for Patient and Population Services to Support Dynamic Client Registration</FP>
                        <FP SOURCE="FP1-2">d. Removal of Reference to OpenID Connect Core Specification</FP>
                        <FP SOURCE="FP1-2">e. API Conditions and Maintenance Updates to Support Dynamic Client Registration</FP>
                        <FP SOURCE="FP1-2">16. New Certification Criteria for Modular API Capabilities</FP>
                        <FP SOURCE="FP1-2">a. Proposal Background</FP>
                        <FP SOURCE="FP1-2">b. Modular API Capabilities Certification Criteria</FP>
                        <FP SOURCE="FP1-2">17. Multi-Factor Authentication Criterion</FP>
                        <FP SOURCE="FP1-2">a. Background</FP>
                        <FP SOURCE="FP1-2">b. Proposal</FP>
                        <FP SOURCE="FP1-2">18. Revised Computerized Provider Order Entry—Laboratory Criterion</FP>
                        <FP SOURCE="FP1-2">19. Revised Standardized API for Patient and Population Services Criterion to Align with Modular API Capabilities</FP>
                        <FP SOURCE="FP1-2">a. Proposed Revisions for Registration</FP>
                        <FP SOURCE="FP1-2">b. Proposed Revisions for Patient and User Access</FP>
                        <FP SOURCE="FP1-2">c. Proposed Revisions for System Access</FP>
                        <FP SOURCE="FP1-2">d. Other Restructured Requirements</FP>
                        <FP SOURCE="FP1-2">e. Proposed Requirements for System Read and Search API, Subscriptions, and Workflow Triggers for Decision Support Interventions</FP>
                        <FP SOURCE="FP1-2">20. Patient, Provider, and Payer APIs</FP>
                        <FP SOURCE="FP1-2">a. Background on CMS Interoperability Rulemaking</FP>
                        <FP SOURCE="FP1-2">b. Proposal Overview</FP>
                        <FP SOURCE="FP1-2">c. Proposed Certification Criteria</FP>
                        <FP SOURCE="FP1-2">d. Revision and Addition of API Condition and Maintenance of Certification Requirements</FP>
                        <FP SOURCE="FP1-2">e. Revisions to Real World Testing Requirements</FP>
                        <FP SOURCE="FP1-2">f. Addition of Criteria to the Base EHR Definition</FP>
                        <FP SOURCE="FP1-2">
                            <E T="03">C. Conditions and Maintenance of Certification Requirements—Insights and Attestations</E>
                        </FP>
                        <FP SOURCE="FP1-2">1. Insights Condition and Maintenance of Certification Requirements</FP>
                        <FP SOURCE="FP1-2">a. Background</FP>
                        <FP SOURCE="FP1-2">b. Process for Reporting Updates</FP>
                        <FP SOURCE="FP1-2">c. Minimum Reporting Qualifications</FP>
                        <FP SOURCE="FP1-2">d. Measure Updates</FP>
                        <FP SOURCE="FP1-2">2. Attestations Condition and Maintenance of Certification Requirements</FP>
                        <FP SOURCE="FP1-2">
                            <E T="03">D. Administrative Updates</E>
                        </FP>
                        <FP SOURCE="FP1-2">1. Program Correspondence</FP>
                        <FP SOURCE="FP1-2">2. ONC-Authorized Certification Bodies (ACB) Surveillance of Certain Maintenance of Certification Requirements</FP>
                        <FP SOURCE="FP1-2">a. Background and Proposal Summary</FP>
                        <FP SOURCE="FP1-2">b. Updates to Principles of Proper Conduct for Maintenance of Certification Requirements</FP>
                        <FP SOURCE="FP1-2">c. Updates to Surveillance for Maintenance of Certification Requirements</FP>
                        <FP SOURCE="FP1-2">3. Updates to Principles of Proper Conduct for API Discovery Details</FP>
                        <FP SOURCE="FP1-2">4. New ONC-ACB Principles of Proper Conduct for Notice of Program Withdrawal</FP>
                        <FP SOURCE="FP1-2">5. Updates to ONC Direct Review Procedures</FP>
                        <FP SOURCE="FP1-2">a. Health IT Developers' Response to Notices of Non-conformity and Corrective Action Plan Requirements</FP>
                        <FP SOURCE="FP1-2">b. Suspension, Termination, and Appeals</FP>
                        <FP SOURCE="FP1-2">c. Appeals</FP>
                        <FP SOURCE="FP1-2">6. Certification Ban</FP>
                        <FP SOURCE="FP1-2">7. Updates Pursuant to 2014 Edition Removal</FP>
                        <FP SOURCE="FP1-2">a. Removal of “Complete EHR” References</FP>
                        <FP SOURCE="FP1-2">b. Removal of “EHR Modules” References</FP>
                        <FP SOURCE="FP1-2">
                            8. Definition of 
                            <E T="03">Serious Risk to Public Health or Safety</E>
                        </FP>
                        <FP SOURCE="FP1-2">9. Removal of Time-limited Criteria</FP>
                        <FP SOURCE="FP1-2">10. Privacy and Security Framework Incorporation of DSI Criterion</FP>
                        <FP SOURCE="FP1-2">
                            <E T="03">E. Correction—Privacy and Security Certification Framework</E>
                        </FP>
                        <FP SOURCE="FP-2">IV. Information Blocking Enhancements</FP>
                        <FP SOURCE="FP1-2">
                            <E T="03">A. Defined Terms</E>
                        </FP>
                        <FP SOURCE="FP1-2">1. Health Care Provider</FP>
                        <FP SOURCE="FP1-2">2. Health Information Technology or Health IT</FP>
                        <FP SOURCE="FP1-2">3. “Interfere With” or “Interference”</FP>
                        <FP SOURCE="FP1-2">
                            a. Application of “Interference” to TEFCA
                            <SU>TM</SU>
                             Requirements
                        </FP>
                        <FP SOURCE="FP1-2">
                            <E T="03">B. Exceptions</E>
                        </FP>
                        <FP SOURCE="FP1-2">1. Privacy Exception</FP>
                        <FP SOURCE="FP1-2">a. Privacy Exception—Definition of Individual</FP>
                        <FP SOURCE="FP1-2">b. Privacy Sub-exception—Interfering with Individual Access Based on Unreviewable Grounds</FP>
                        <FP SOURCE="FP1-2">c. Privacy Sub-exception—Individual's Request Not to Share EHI</FP>
                        <FP SOURCE="FP1-2">2. Infeasibility Exception</FP>
                        <FP SOURCE="FP1-2">a. Segmentation Condition Modifications</FP>
                        <FP SOURCE="FP1-2">b. Third Party Seeking Modification Use Condition Modifications</FP>
                        <FP SOURCE="FP1-2">c. Responding to Requests Condition Modifications</FP>
                        <FP SOURCE="FP1-2">3. Protecting Care Access Exception</FP>
                        <FP SOURCE="FP1-2">a. Background and Purpose</FP>
                        <FP SOURCE="FP1-2">b. Threshold Condition and Structure of Exception</FP>
                        <FP SOURCE="FP1-2">c. Patient Protection Condition</FP>
                        <FP SOURCE="FP1-2">d. Care Access Condition</FP>
                        <FP SOURCE="FP1-2">e. Clarifying Provisions: Presumption and Definition of “Legal Action”</FP>
                        <FP SOURCE="FP1-2">4. Requestor Preferences Exception</FP>
                        <FP SOURCE="FP1-2">
                            5. Exceptions That Involve Practices Related to Actors' Participation in The Trusted Exchange Framework and Common Agreement
                            <SU>TM</SU>
                             (TEFCA
                            <SU>TM</SU>
                            )
                        </FP>
                        <FP SOURCE="FP1-2">a. Definitions</FP>
                        <FP SOURCE="FP1-2">
                            b. TEFCA
                            <E T="51">TM</E>
                             Manner Exception
                        </FP>
                        <FP SOURCE="FP-2">
                            V. Trusted Exchange Framework and Common Agreement
                            <SU>TM</SU>
                        </FP>
                        <FP SOURCE="FP1-2">
                            <E T="03">A. Subpart A—General Provisions</E>
                        </FP>
                        <FP SOURCE="FP1-2">
                            <E T="03">B. Subpart B—Qualifications for Designation</E>
                        </FP>
                        <FP SOURCE="FP1-2">
                            <E T="03">
                                C. Subpart C—QHIN
                                <SU>TM</SU>
                                 Onboarding and Designation Processes
                            </E>
                        </FP>
                        <FP SOURCE="FP1-2">
                            <E T="03">D. Subpart D—Suspension</E>
                        </FP>
                        <FP SOURCE="FP1-2">
                            <E T="03">E. Subpart E—Termination</E>
                        </FP>
                        <FP SOURCE="FP1-2">
                            <E T="03">F. Subpart F—Review of RCE® or ONC Decisions</E>
                        </FP>
                        <FP SOURCE="FP1-2">
                            <E T="03">G. Subpart G—QHIN</E>
                            <E T="51">TM</E>
                              
                            <E T="03">Attestation for the Adoption of the Trusted Exchange Framework and Common Agreement</E>
                            <E T="51">TM</E>
                        </FP>
                        <FP SOURCE="FP-2">VI. Incorporation by Reference</FP>
                        <FP SOURCE="FP-2">
                            VII. Response to Comments
                            <PRTPAGE P="63500"/>
                        </FP>
                        <FP SOURCE="FP-2">VIII. Collection of Information Requirements</FP>
                        <FP SOURCE="FP1-2">
                            <E T="03">A. Qualified Health Information Networks</E>
                            <SU>TM</SU>
                        </FP>
                        <FP SOURCE="FP1-2">
                            <E T="03">B. ONC-ACBs</E>
                        </FP>
                        <FP SOURCE="FP-2">IX. Regulatory Impact Analysis</FP>
                        <FP SOURCE="FP1-2">
                            <E T="03">A. Statement of Need</E>
                        </FP>
                        <FP SOURCE="FP1-2">
                            <E T="03">B. Alternatives Considered</E>
                        </FP>
                        <FP SOURCE="FP1-2">
                            <E T="03">C. Overall Impact</E>
                        </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">
                            <E T="03">D. Regulatory Flexibility Act</E>
                        </FP>
                        <FP SOURCE="FP1-2">
                            <E T="03">E. Executive Order 13132—Federalism</E>
                        </FP>
                        <FP SOURCE="FP1-2">
                            <E T="03">F. Unfunded Mandates Reform Act of 1995</E>
                        </FP>
                        <HD SOURCE="HD1">Regulation Text</HD>
                    </EXTRACT>
                    <HD SOURCE="HD1">I. Executive Summary</HD>
                    <HD SOURCE="HD2">A. Purpose of Regulatory Action</HD>
                    <P>
                        The Secretary of Health and Human Services has delegated responsibilities to the Office of the National Coordinator for Health Information Technology (ONC) for the implementation of certain provisions in Title IV of the 21st Century Cures Act (Pub. L. 114-255, Dec. 13, 2016) (Cures Act) that are designed to: advance interoperability; support the access, exchange, and use of electronic health information (EHI); and identify reasonable and necessary activities that do not constitute information blocking.
                        <SU>1</SU>
                        <FTREF/>
                         ONC is responsible for implementation of certain provisions of the Health Information Technology for Economic and Clinical Health Act (Pub. L. 111-5, Feb. 17. 2009) (HITECH Act) including: 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, among other goals; and requirements to keep or recognize a program or programs for the voluntary certification of health information technology. This proposed rule seeks to fulfill statutory requirements; provide transparency; advance equity, innovation, and interoperability; and support the access to, and exchange and use of, EHI. Transparency regarding healthcare information and activities—as well as the interoperability and electronic exchange of health information—are all in the best interest of the patient and are central to the efforts of the Department of Health and Human Services to enhance and protect the health and well-being of all Americans.
                    </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, C and D. ONC's official website, HealthIT.gov, 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>In addition to addressing the HITECH Act's and Cures Act's requirements described above and advancing interoperability, the proposed rule aligns with and supports Executive Orders (E.O.) 13994, 13985, 14036, and 14058. The President issued E.O. 13994 on January 21, 2021, to ensure a data-driven response to COVID-19 and future high-consequence public health threats. The Cures Act and the information blocking provisions in the 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program (85 FR 25642) (ONC Cures Act Final Rule) have enabled critical steps to making data available across the healthcare system. The proposed rule proposes to adopt certification criteria to advance interoperability and support public health reporting and exchange. Because we recognize the need for greater interoperability of public health technology and access to more actionable data by public health authorities (PHA) and their partners, the proposed rule lays out a multi-pronged approach that takes advantage of, and builds upon, the various previous efforts to advance public health reporting, including advancements in HL7® Fast Healthcare Interoperability Resources-based (FHIR®) solutions and evolving standards related to public health interoperability. We have proposed this approach to allow for systems to mature and advance in an aligned fashion, reduce the need for manual workarounds and intervention, and lead to wider adoption of advanced standards-based capabilities.</P>
                    <P>
                        The proposed adoption of the United States Core Data for Interoperability Standard Version 4 (USCDI v4) would promote the establishment and use of interoperable data sets of EHI for interoperable health data exchange. As discussed in section III.B.1, USCDI v4 would facilitate the collection, access and exchange of data for use in public health and emergency response (
                        <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 proposal to adopt a new certification criterion for standardized FHIR-based application programming interfaces (APIs) for public health reporting, as discussed in section III.B.13.f, reflects ONC's continued efforts to develop and standardize APIs and facilitate exchange of public health data between health care providers and public health agencies, to securely access EHI through the broader adoption of standardized APIs.
                        <SU>2</SU>
                         
                        <SU>3</SU>
                        <FTREF/>
                        As discussed in section III.B, adopting USCDI v4 and the proposals in § 170.315(g)(20) are intended to facilitate core public health missions including detecting and monitoring, investigating and responding, informing and disseminating, and being response-ready. We also expect our proposed changes to improve patient access to more complete, standardized, immunization information stored in certified health IT products.
                    </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) established 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 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 committed to advancing health equity, and this proposed rule is consistent with E.O. 13985 of January 20, 2021, Advancing Racial Equity and Support for Underserved Communities Through the Federal Government.
                        <SU>4</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 any policies and programs that serve as barriers to equal opportunity.” We believe USCDI v4 and proposals in § 170.315(f) and § 170.315(g)(20) would not only support identifying and responding to public health threats, but also support advancing equity. As noted above, we propose to modify current certification 
                        <PRTPAGE P="63501"/>
                        criteria in § 170.315(f) and adopt new criteria in § 170.315(f) for Health IT Modules supporting public health data exchange that would help increase the data shared between health care providers, laboratories, and PHAs, and would increase interoperability among the different systems in place at each entity. Our proposed changes focus on providing more complete patient-level information for contact tracing and further case investigation, patient outreach, direct care, and other clinical and public health activities. For example, some of the proposed standards would require the exchange of available patient demographic information, including race, ethnicity, sex, and contact information; and may allow PHAs to get more complete data when providers and laboratories have these data elements and can appropriately fill the fields. Additionally, if finalized as proposed, the adoption of USCDI v4 would update the USCDI standard to include new data elements under the Health Status Assessments, Medications, Allergies and Intolerances, Goals and Preferences, Encounter Information, Vital Signs, and Laboratory data classes, and a new data class, Facility Information, as discussed in section III.B.1 of this proposed rule. Expanding the data elements included in USCDI would increase the amount and type of data available to be used and exchanged through certified health IT. Our proposed standards update for public health and USCDI v4 could help capture more accurate and complete patient characteristics that are reflective of patient diversity and could potentially help data users address disparities in health outcomes for all patients, including those who may be marginalized and underrepresented. This could also support 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 through 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>
                    <P>As discussed in section III.B.1, the proposal to adopt USCDI v4 also supports the concept of “health equity by design,” where health equity considerations are identified and incorporated from the beginning and throughout the technology design, build, and implementation processes, and health equity strategies, tactics, and patterns are guiding principles for developers, enforced by technical architecture, and built into the technology at every layer. With every successive USCDI version supported by certified health IT, the capabilities and workflows included will help support equity and efforts to reduce disparities.</P>
                    <P>
                        President Biden's E.O. 14036, Promoting Competition in the American Economy,
                        <SU>5</SU>
                        <FTREF/>
                         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>6</SU>
                        <FTREF/>
                         This proposed rule would foster 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 throughout the proposed rule, competition would be advanced through these improved API standards that can help individuals connect to their information and can help health care providers involved in the patient's care to 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 and more choices in their health care providers. This is similar to how APIs have impacted other sectors of the economy, such as travel, banking, and commerce.
                    </P>
                    <FTNT>
                        <P>
                            <SU>5</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 through36999, 
                            <E T="03">https://www.federalregister.gov/documents/2021/07/14/2021-15069/promoting-competition-in-the-american-economy</E>
                            .
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>6</SU>
                             
                            <E T="04">Federal Register</E>
                            : Steps to Increase Competition and Better Inform Consumers and Workers to Support Continued Growth of the American Economy.
                        </P>
                    </FTNT>
                    <P>
                        Further, as described in section IV of this proposed rule, we propose enhancements to support information sharing under the information blocking regulations and promote innovation and competition, while ensuring patients' privacy and access to care remain protected. 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, as discussed in both the ONC Cures Act Proposed (84 FR 7508) and Final (85 FR 25790 through 25791) Rules, and reiterated in the Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing (HTI-1) Final Rule (89 FR 1192). Specifically, we described how the information blocking provisions provide a comprehensive response to the issues identified by empirical and economic research that suggested that information blocking may weaken competition, encourage consolidation, and create barriers to entry for developers of new and innovative applications and technologies that enable more effective uses of EHI to improve population health and the patient experience.
                        <SU>7</SU>
                        <FTREF/>
                         We explained that the information blocking provision 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 (89 FR 1195, citing section 3022(a)(2) of the PHSA). Actors subject to the information blocking provisions may, 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>8</SU>
                        <FTREF/>
                         Information blocking may also harm competition not just 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 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 providers vulnerable to acquisition or inducement into arrangements that enhance the market power of incumbent providers to the detriment of consumers and purchasers 
                        <PRTPAGE P="63502"/>
                        of healthcare services (85 FR 25820). The implementation of the new information blocking provisions proposed and discussed in section IV of this proposed rule would continue to promote innovation and support the lawful access, exchange, and use of EHI, while strengthening support for individuals' privacy and EHI sharing preferences.
                    </P>
                    <FTNT>
                        <P>
                            <SU>7</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>8</SU>
                             
                            <E T="03">See also</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>
                            .
                        </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 and effective delivery of services with a focus on the experience of individuals, health IT developers, and health care providers.
                        <SU>9</SU>
                        <FTREF/>
                         The proposed rule supports the Department of Health and Human Services' agency-wide approach to electronic prior authorization that meets the Department's interoperability and burden reduction goals, such as reducing documentation requirements associated with completing prior authorization requests for payers.
                        <SU>10</SU>
                        <FTREF/>
                         Proposed certification criteria would make available certified health IT that can enable payers contracting with the Federal government, such as Medicare Advantage plans, to meet Centers for Medicare &amp; Medicaid Services (CMS) requirements for sharing information. Additionally, improving the equitable access, exchange, and use of EHI would help enable patient-centric care, which is expected to improve equity in health outcomes. This proposed rule further recognizes patient feedback and preferences in their care and how patients and their representatives may want to monitor and share EHI with relevant health care providers and entities. The health IT certification provisions of the proposed rule aim to reduce the burden associated with prior authorization processes, which can ensure that patients receive the care they need in a timely manner, lower administrative cost, and reduce the complexity of obtaining a prior authorization for health care providers and patients. Collectively, these provisions of the proposed rule help advance the equitable and effective delivery of services with a focus on the experience of individuals, health IT developers, and health care providers.
                    </P>
                    <FTNT>
                        <P>
                            <SU>9</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 through71366, 
                            <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>
                    <FTNT>
                        <P>
                            <SU>10</SU>
                             
                            <E T="03">Strategy on Reducing Regulatory and Administrative Burden Relating to the Use of Health IT and EHRs (Burden Reduction Report),</E>
                             February 2020, pages 26-28, 
                            <E T="03">https://www.healthit.gov/sites/default/files/page/2020-02/BurdenReport_0.pdf</E>
                            .
                        </P>
                    </FTNT>
                    <P>
                        We also strive to further advance Federal agency coordination. ONC works with CMS to ensure that our certification criteria and standards support and complement CMS programs that reference ONC regulations, such as the Medicare Promoting Interoperability Program and the Promoting Interoperability performance category of the Merit-based Incentive Payment System (MIPS). In addition, a final rule titled “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” (CMS Interoperability and Prior Authorization final rule, 89 FR 8758) appeared in the 
                        <E T="04">Federal Register</E>
                         on February 8, 2024, and included requirements for certain payers regulated by CMS to establish APIs that can facilitate electronic prior authorization processes by 2027 (89 FR 8919). CMS also finalized electronic prior authorization measures for eligible clinicians who participate in the Promoting Interoperability performance category of the MIPS; and eligible hospitals and critical access hospitals that participate in the Medicare Promoting Interoperability Program, beginning in the CY 2027 performance period and the EHR reporting period in CY 2027, respectively (89 FR 8760). In this proposed rule, we propose to adopt standards and establish certification criteria to facilitate electronic prior authorization using certified health IT, which providers can use to complete the required actions under the finalized measures. Lastly, we are committed to our continued, collaborative work with the Centers for Disease Control and Prevention (CDC) on improving public health data systems. The proposed updates to the ONC Health IT Certification Program's public health criteria and complementary public health criteria for PHA systems would support CDC's Data Modernization Initiative and Public Health Data Strategy.
                        <SU>11</SU>
                        <FTREF/>
                         We believe these approaches would increase efficiency for delivery of services and programs, reduce confusion for participants in these programs, and better serve the public interest.
                    </P>
                    <FTNT>
                        <P>
                            <SU>11</SU>
                             Public_Health_Data_Strategy-final-P.pdf (cdc.gov).
                        </P>
                    </FTNT>
                    <P>
                        While this rulemaking does not propose to require entities to adopt any specific standards to ensure that their information and communication technology (ICT), including software, applications, websites, and electronic documents, is accessible for people with disabilities, entities covered by this rule may also be subject to applicable requirements of Federal nondiscrimination laws. For example, Section 504 of the Rehabilitation Act of 1973 (Section 504) prohibits recipients of Federal financial assistance from discriminating on the basis of disability by excluding people with disabilities from participation in, denying them the benefits of, or subjecting them to discrimination in their programs or activities. 29 U.S.C. 794. Section 1557 of the Patient Protection and Affordable Care Act (Section 1557) prohibits certain health programs and activities, including those receiving Federal financial assistance from HHS, from discriminating on the basis of race, color, national origin, sex, age, or disability by excluding them from participation in, denying them the benefits of, or subjecting them to discrimination in their health programs or activities. 42 U.S.C. 18116(a). Newly issued Section 504 regulations require recipients to ensure that web content and mobile apps that a recipient provides or makes available, directly or through contractual, licensing, or other arrangements, be readily accessible to and usable by individuals with disabilities, with some exceptions. 
                        <E T="03">See</E>
                         89 FR 40066 and 45 CFR Secs. 84.82-.89(a). The rule requires technical accessibility standards that must be met on May 11, 2026, for entities with fifteen or more employees and May 10, 2027, for entities with fewer than fifteen employees unless the recipient can demonstrate that compliance with this section would result in a fundamental alteration in the nature of a program or activity or in undue financial and administrative burdens or unless an exception applies. 45 CFR Sec. 84.84(b); 84.85. Title III of the Americans with Disabilities Act (ADA) prohibits discrimination on the basis of disability in the full and equal enjoyment of places of public accommodation. 42 U.S.C. 12182. Title II of the ADA prohibits state and local government 
                        <PRTPAGE P="63503"/>
                        entities from discriminating on the basis of disability by excluding people with disabilities from participation in, denying them the benefits of, or subjecting them to discrimination in their services, programs, or activities. 42 U.S.C. 12132. On April 24, 2024, the Department of Justice published regulations establishing specific requirements, including the adoption of specific technical standards, for making accessible the services, programs, and activities offered by State and local government entities through the web and mobile applications. 89 FR 31320. More generally, these statutes and their implementing regulations apply to programs, services and activities implemented through or with information and communications technology (ICT). In addition, the Section 1557 implementing regulation addresses ICT specifically, providing that covered entities, including health programs and activities that receive Federal financial assistance from HHS, shall ensure that their health programs or activities provided through ICT are accessible to individuals with disabilities, unless doing so would result in undue financial and administrative burdens or a fundamental alteration in the nature of the health programs or activities. 89 FR 37522 (May 6, 2024) (45 CFR 92.204).
                    </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. New and Revised Standards and Certification Criteria</HD>
                    <HD SOURCE="HD3">i. The United States Core Data for Interoperability Version 4 (USCDI v4)</HD>
                    <P>The USCDI standard in § 170.213 is a baseline set of data that can be commonly exchanged across care settings for a wide range of uses. Certain certification criteria in the ONC Health IT Certification Program (Program) currently require the use of one of the versions of the USCDI standard by in § 170.213. We propose to update the USCDI standard in § 170.213 by adding USCDI v4 and by establishing an expiration date of January 1, 2028, for USCDI v3 for purposes of the Program. We propose to add USCDI v4 in § 170.213(c) and incorporate it by reference in § 170.299. We propose that up to and including December 31, 2027, a Health IT Module certified to certification criteria referencing § 170.213 may use either version of the standard. We propose that by January 1, 2028, a health IT developer of a Health IT Module certified to certification criteria referencing § 170.213 must update its Health IT Module to USCDI v4 and provide the updated version to their customers in order to maintain certification of that Health IT Module. We propose that any Health IT Modules seeking certification to certification criteria referencing § 170.213 on or after January 1, 2028, would need to be capable of exchanging the data elements that the USCDI v4 comprises.</P>
                    <HD SOURCE="HD3">ii. SMART App Launch 2.2</HD>
                    <P>As discussed in section III.B.2, we propose to adopt the HL7® FHIR® SMART Application Launch Framework Implementation Guide release 2.2.0 (SMART v2.2 Guide) in § 170.215(c)(3). We propose that the adoption of the SMART v2 Guide in § 170.215(c)(2) expires on January 1, 2028. We propose that a Health IT Module certified to criteria referencing the implementation specifications in § 170.215(c) may use the SMART v1, SMART v2, or SMART v2.2 guides for the time period up to and including December 31, 2025. Then, by January 1, 2026, when the adoption of SMART v1 expires, a health IT developer of a Health IT Module certified to certification criteria referencing the implementation specifications in § 170.215(c) must update its Health IT Module to either the SMART v2 or SMART v2.2 Guides and provide the updated version to its customers in order to maintain certification of that Health IT Module. Then, by January 1, 2028, when the adoption of the SMART v2 Guide expires, a health IT developer of a Health IT Module certified to certification criteria referencing the implementation specifications in § 170.215(c) must update its Health IT Module to the SMART v2.2 Guide and provide the updated version to its customers in order to maintain certification of that Health IT Module. On and after January 1, 2028, we propose that any Health IT Modules seeking certification to certification criteria referencing the implementation specifications in § 170.215(c), would need to be capable of supporting SMART v2.2 Guide functionality.</P>
                    <HD SOURCE="HD3">iii. User-Access Brands and Endpoints</HD>
                    <P>We propose to adopt the User-access Brands and Endpoints (Brands) specification for our service base URL publication requirements, as explained in section III.B.3. This applies to our current service base URL publication requirements in § 170.404(b)(2), where we propose to reorganize the criterion's paragraphs in a way that places existing service base URL requirements into § 170.404(b)(2)(i) and (ii) and adds the new Brands requirement in § 170.404(b)(2)(iii). We propose in our updated § 170.404(b)(2)(iii) to require that, by January 1, 2028, service base URLs and related API Information Source details, including each organization's name, location, and facility identifier, must be published in an aggregate vendor-consolidated “FHIR Bundle” according to the Brands specification. Additionally, in our proposal to revise § 170.404(b)(3) where we propose new requirements for the publication of API discovery details for payer network information, including service base URLs and API Information Source details, we propose to adopt Brands specification.</P>
                    <HD SOURCE="HD3">iv. Standards for Encryption and Decryption of Electronic Health Information</HD>
                    <P>As discussed in section III.B.4, we propose to adopt the updated version of Annex A of the Federal Information Processing Standards (FIPS) 140-2 (Draft, October 12, 2021) in § 170.210(a)(3) and incorporate it by reference in § 170.299. We propose to add an expiration date of January 1, 2026, to the FIPS 140-2 (October 8, 2014) version of the standard presently adopted in § 170.210(a)(2). We also propose to remove the standard found in § 170.210(f), which is no longer referenced in any active certification criteria. Revising § 170.210(a) by adding an expiration date in § 170.210(a)(2) and a new version of the FIPS standard in § 170.210(a)(3) would impact three certification criteria that currently reference the standard in § 170.210(a)(2), including § 170.315(d)(7) “end-user device encryption;” (d)(9) “trusted connection;” and (d)(12) “encrypt authentication credentials.” Note that we also propose to change the names of the certification criteria in § 170.315(d)(7) and (d)(12) to “health IT encryption” and “protect stored authentication credentials” respectively, as discussed in sections III.B.11 and III.B.12 of this preamble.</P>
                    <HD SOURCE="HD3">v. Minimum Standards Code Sets Updates</HD>
                    <P>
                        Early in ONC's standards and certification rulemakings, we established a policy of adopting newer versions of “minimum standards” code sets that update frequently (
                        <E T="03">e.g.,</E>
                         77 FR 54170 and 80 FR 62612). Adopting newer versions of these code sets enables improved interoperability and implementation of health IT with minimal additional burden. If adopted, newer versions of these minimum standards code sets would serve as the baseline for certification, and 
                        <PRTPAGE P="63504"/>
                        developers of certified health IT would be able to use newer versions of these adopted standards on a voluntary basis. Because these code sets are updated frequently, we will consider whether it may be more appropriate to adopt a version of a minimum standards code set issued after publication of this proposed rule, but before publication of a final rule. In section III.B.5, we discuss our proposals to adopt newer versions 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(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>
                    <HD SOURCE="HD3">vi. New Imaging Requirements for Health IT Modules</HD>
                    <P>We propose, as explained in section III.B.6, to revise the certification criteria adopted in § 170.315(b)(1), (e)(1), (g)(9), and (g)(10) to include new certification requirements to support access, exchange, and use of diagnostic images via imaging links. However, we are not proposing a specific standard associated with the support of this functionality, and we note that this requirement can be met with a context-sensitive link to an external application which provides access to images and their associated narrative. We believe that this proposal, if finalized as proposed, will promote more consistent access to images for providers and patients. We propose that by January 1, 2028, a health IT developer of a Health IT Module certified to the certification criteria related to “transitions of care” in § 170.315(b)(1), “view, download, and transmit” in § 170.315(e)(1), “application access—all data request,” in § 170.315(g)(9), and “standardized API for patient and population services,” in § 170.315(g)(10) must update their Health IT Module and provide the updated version to their customers to maintain certification of that Health IT Module.</P>
                    <HD SOURCE="HD3">vii. Revised Clinical Information Reconciliation and Incorporation Criterion</HD>
                    <P>We propose, as described in section III.B.7, a primary proposal and an alternative proposal for revising the “clinical information reconciliation and incorporation” certification criterion in § 170.315(b)(2) to expand the number and types of data elements that Health IT Modules certified to this criterion would be required to reconcile and incorporate. Our primary proposal would require Health IT Modules certified to § 170.315(b)(2) to be capable of reconciling and incorporating all USCDI data elements according to at least one of the versions of the USCDI standard specified in § 170.213. Our alternative proposal would require Health IT Modules to reconcile and incorporate data elements from six additional USCDI data classes beyond the existing three data classes required as part of the current certification criterion's functionality. We also propose new functional requirements to enable user-driven automatic reconciliation and incorporation. We propose that by January 1, 2028, a health IT developer of a Health IT Module certified to the criterion in § 170.315(b)(2) must update their Health IT Module and provide the updated version to their customers in order to maintain certification of that Health IT Module. We also propose that any Health IT Modules seeking certification for the criterion in § 170.315(b)(2) on or after January 1, 2028, would need to be capable of supporting this functionality.</P>
                    <HD SOURCE="HD3">viii. Revised Electronic Prescribing Certification Criterion</HD>
                    <P>
                        We propose to incorporate the National Council for Prescription Drug Programs (NCPDP) SCRIPT standard 
                        <SU>12</SU>
                        <FTREF/>
                         version 2023011 in an updated version of the electronic prescribing certification criterion in § 170.315(b)(3)(ii). Under this proposal, as described in section III.B.8 of this proposed rule, health IT developers may maintain health IT certification conformance with the current version of the criterion using NCPDP SCRIPT standard version 2017071 for the time period up to and including December 31, 2027. We propose that by January 1, 2028, a health IT developer of a Health IT Module certified to the criterion in § 170.315(b)(3) must update the Health IT Module to use the NCPDP SCRIPT standard version 2023011 and provide that update to their customers in order to maintain certification of the Health IT Module. We propose that any Health IT Modules for which a health IT developer seeks certification to the criterion in § 170.315(b)(3) on or after January 1, 2028, would need to be able to perform the required prescription-related electronic transaction in accordance with the NCPDP SCRIPT standard version 2023011. We also propose a series of updates to the transactions included in § 170.315(b)(3)(ii) including removing transactions currently identified as optional for the certification criterion.
                    </P>
                    <FTNT>
                        <P>
                            <SU>12</SU>
                             
                            <E T="03">See https://standards.ncpdp.org/</E>
                            .
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">ix. New Real-Time Prescription Benefit Criterion</HD>
                    <P>Real-time prescription benefit tools empower providers and their patients to compare the patient-specific cost of a drug to the cost of a suitable alternative, compare prescription costs at different pharmacies, view information about out-of-pocket costs, and learn whether prior authorization for a specific drug is required. In order to implement section 119(b)(3) of the Consolidated Appropriations Act, 2021 (Pub. L. 116-260), as discussed in section III.B.9, we propose to establish a real-time prescription benefit certification criterion in § 170.315(b)(4) based on the National Council for Prescription Drug Programs (NCPDP) Real-Time Prescription Benefit (RTPB) standard version 13. We also propose to include this certification criterion in the Base EHR definition in § 170.102.</P>
                    <HD SOURCE="HD3">x. Electronic Health Information (EHI) Export—Single Patient EHI Export Exemption</HD>
                    <P>As explained in section III.B.10, we propose to exempt Health IT Modules that act primarily as intermediaries between systems and, through integration, function without any direct human interaction from the requirement in § 170.315(b)(10)(i)(B) to provide functionality without subsequent developer assistance to operate. We propose that this exemption proposed in § 170.315(b)(10)(i)(F) would be available if the developer of such a Health IT Module receives fewer than ten requests in the immediately preceding calendar year for a single patient EHI export. Relatedly, we propose in § 170.402(b)(2)(iii) that developers of certified health IT with Health IT Modules certified to § 170.315(b)(10) that claim the exemption proposed in § 170.315(b)(10)(i)(F) would need to report the number of requests for single patient EHI export on an annual basis to their ONC-Authorized Certification Bodies (ACBs) by March 1 of each calendar year beginning in 2028.</P>
                    <HD SOURCE="HD3">xi. Revised End-User Device Encryption Criterion</HD>
                    <P>
                        As discussed in section III.B.11, we propose to revise § 170.315(d)(7) to include a new requirement that Health IT Modules certified to this criterion encrypt EHI stored server-side on and after January 1, 2026. To include this new requirement, we propose reorganizing the certification criterion's paragraphs in a way that places existing 
                        <PRTPAGE P="63505"/>
                        end-user device encryption requirements into § 170.315(d)(7)(i) and (d)(7)(ii) and adds the new server encryption requirement in § 170.315(d)(7)(iii). Then, we propose placing the applicable proposed encryption standard and default settings requirements to both the end-user device and server encryption requirements into § 170.315(d)(7)(iii) and (iv) respectively. We also propose to require that personally identifiable information must be encrypted in Health IT Modules certified to this revised certification criterion. Finally, we propose to change § 170.315(d)(7) by renaming it to “health IT encryption,” to better describe the end-user and proposed server-side requirements together.
                    </P>
                    <HD SOURCE="HD3">xii. Revised Criterion for Encrypt Authentication Credentials</HD>
                    <P>As explained in section III.B.12, we propose to revise the “encrypt authentication credentials” certification criterion in § 170.315(d)(12). We propose to revise the certification criterion by expiring our current “yes” or “no” attestation requirement and replacing it with a new requirement that Health IT Modules that store authentication credentials protect the confidentiality and integrity of its stored authentication credentials according to the Federal Information Processing Standards (FIPS) 140-2 (October 12, 2021) industry standard. We also propose to change the name of this certification criterion to “protect stored authentication credentials,” to better describe how we propose to revise the criterion.</P>
                    <HD SOURCE="HD3">xiii. Health IT Modules Supporting Public Health Data Exchange</HD>
                    <P>
                        Public health promotes and protects the health of all people and their communities. To accomplish this mission, public health authorities (PHAs) rely in part on public health information exchange, including data from healthcare facilities and providers, laboratories, schools, social and community service providers, and other data partners to acquire the information they need. However, PHAs often do not have access to—or, often, the ability to share—the data required to optimally address public health needs (emergent or otherwise) due to the lack of common standards utilized in the reported data, variable reporting requirements, limited interoperability of systems, or inadequate public health data infrastructure and technology. Considering the need for greater interoperability of public health technology and access to more actionable data by PHAs and their partners,
                        <SU>13</SU>
                        <FTREF/>
                         as discussed in section III.B.13, we propose: to revise the Program's current certification criteria related to public health in § 170.315(f), including referencing newer versions of respective exchange and vocabulary standards in the current § 170.315(f) certification criteria (§ 170.315(f)(1)-(f)(7)); proposing two additional certification criteria for birth reporting (§ 170.315(f)(8)) and bi-directional exchange with a prescription drug monitoring program (PDMP) (§ 170.315(f)(9)); proposing new certification criteria for Health IT Modules supporting public health data exchange in § 170.315(f)(21)-(25), (28) and (29); and, proposing a new certification criterion for a standardized FHIR®-based API for public health data exchange in § 170.315(g)(20). The new certification criterion in § 170.315(g)(20) would support ongoing and future development of public health FHIR IGs leveraging a core set of existing, modular, and extensible capabilities and standards. The standards referenced in the proposed § 170.315(g)(20) certification criterion support FHIR capabilities such as API-based event notifications (
                        <E T="03">i.e.,</E>
                         FHIR Subscriptions), SMART App Launch, Bulk Data Export, and requirements for authorization and authentication, drawing on the Program's requirements for Health IT Modules certified to § 170.315(g)(10).
                    </P>
                    <FTNT>
                        <P>
                            <SU>13</SU>
                             
                            <E T="03">https://www.gao.gov/products/gao-22-106175</E>
                            .
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">xiv. Bulk Data Enhancements</HD>
                    <P>We propose, as discussed in section III.B.14, to adopt the HL7® FHIR® Bulk Data Access v2.0.0: STU 2 implementation specification (Bulk v2 IG) in § 170.215(d)(2). We also propose to require, in many of our proposed certification criteria that reference § 170.215(d)(2), server support for the “group export” operation and a “_type” query parameter for performance improvement. We believe this proposal would better support interoperability with Health IT Modules certified to support FHIR Bulk Data Access and better enable performant exporting of complete sets of FHIR resources for pre-defined cohorts of patients. This would raise the floor from our current Bulk v1 IG requirements for certification, where we require support for the group export operation but do not require support for any of the optional query parameters in the IG. We believe that these new certification requirements, based on additional implementer clarifications included in the Bulk v2 IG, would provide meaningful improvements in the performance of Bulk APIs. Additionally, we welcome comment on the issues hindering the effective exchange of population data using Bulk FHIR APIs and additional steps ONC can take to help address those issues.</P>
                    <HD SOURCE="HD3">xv. New Requirements To Support Dynamic Client Registration Protocol in the Program</HD>
                    <P>We propose, as explained in section III.B.15, to add requirements in the Program to support dynamic client registration and subsequent authentication and authorization for dynamically registered apps for patient-facing, user-facing, and system confidential applications. This includes adding requirements to the following in the Program:</P>
                    <FP SOURCE="FP-1">• § 170.315(g)(10) certification criterion</FP>
                    <FP SOURCE="FP-1">• § 170.315(g)(20), (30), and (32)-(35) proposed certification criteria</FP>
                    <FP SOURCE="FP-1">• § 170.315(j)(2), (5), (8), (11) proposed certification criteria</FP>
                    <FP SOURCE="FP-1">• API Conditions and Maintenance of Certification requirements in § 170.404</FP>
                    <P>
                        We propose to adopt the HL7® Unified Data Access Profiles (UDAP
                        <E T="51">TM</E>
                        ) Security for Scalable Registration, Authentication, and Authorization Implementation Guide Release 1.0.0 implementation guide (UDAP Security IG v1), and we propose to require several specific sections of it to support requirements in the Program criteria listed above. This proposal would facilitate timelier patient, provider, and system access to health information using applications by providing a more uniform, standardized, and automated application registration pathway.
                    </P>
                    <HD SOURCE="HD3">xvi. New Certification Criteria for Modular API Capabilities</HD>
                    <P>
                        We propose, as discussed in section III.B.16, to add a new category of certification criteria to § 170.315 titled “modular API capabilities” in § 170.315(j). Several proposals across this proposed rulemaking would establish capabilities necessary to support standardized APIs across clinical, public health, administrative, and other use cases. We propose that the certification criteria in § 170.315(j) would represent API capabilities that are standards-based, including through new standards, such as HL7® Clinical Decision Support (CDS) Hooks, SMART Health Cards, and HL7 FHIR® Subscriptions, as well as standards and functionalities historically referenced in § 170.315(g)(10). These modular API capabilities would be referenced and incorporated into Health IT Modules to support standardized APIs for clinical use cases in § 170.315(g)(10), public 
                        <PRTPAGE P="63506"/>
                        health use cases in § 170.315(g)(20), and health insurance and coverage use cases in § 170.315(g)(30)-(36), as well as other future use cases across the health IT landscape.
                    </P>
                    <HD SOURCE="HD3">xvii. Multi-Factor Authentication Criterion</HD>
                    <P>As explained in section III.B.17, we propose to revise the “multi-factor authentication” (MFA) certification criterion in § 170.315(d)(13) and accordingly update the privacy and security (P&amp;S) certification framework in § 170.550(h). The proposed update would revise our MFA certification criterion by replacing our current “yes” or “no” attestation requirement with a specific requirement to support multi-factor authentication and configuration for three certification criteria on and after January 1, 2028. We propose to apply the updated MFA requirements by revising each of the certification criteria in § 170.315(b)(3), (e)(1), (g)(10), and (g)(30) to require that a Health IT Module certified to these criteria also be certified to § 170.315(d)(13)(ii) on and after January 1, 2028. Given our proposal to embed § 170.315(d)(13) references into each applicable certification criterion, § 170.315(d)(13) does not need to be referenced again in § 170.550(h)(3), therefore, we propose to expire all the references to § 170.315(d)(13) in § 170.550(h)(3) by December 31, 2027. We believe these updates would match industry best practices for information security, particularly for important authentication use cases in certified health IT.</P>
                    <HD SOURCE="HD3">xviii. Revised Computerized Provider Order Entry—Laboratory Criterion</HD>
                    <P>We propose, as discussed in section III.B.18, to update the “computerized provider order entry—laboratory” certification criterion in § 170.315(a)(2) to require enabling a user to create and transmit laboratory orders electronically according to the standard proposed in § 170.205(g)(2), the HL7® Laboratory Order Interface (LOI) Implementation Guide (IG). We further propose to update § 170.315(a)(2) to require technology to receive and validate laboratory results according to the standard proposed in § 170.205(g)(3), the HL7® Laboratory Results Interface (LRI) IG. Ensuring that systems creating laboratory orders can transmit orders and receive associated results and values electronically, according to national standards, would create more complete patient information available to clinicians throughout the laboratory workflow. We propose that by January 1, 2028, a health IT developer of a Health IT Module certified to the criterion in § 170.315(a)(2) must update its Health IT Module and provide the updated version to its customers in order to maintain certification of that Health IT Module. We propose that any Health IT Modules seeking certification for the criterion in § 170.315(a)(2) on or after January 1, 2028, would need to be capable of supporting this functionality.</P>
                    <HD SOURCE="HD3">xix. Revised Standardized API for Patient and Population Services Criterion To Align With Modular API Capabilities</HD>
                    <P>As discussed in section III.B.19, we propose to revise the certification criterion in § 170.315(g)(10) to reorganize requirements to improve clarity and align with new proposals in this rule, including proposed:</P>
                    <FP SOURCE="FP-1">• restructuring of existing requirements to reference the “modular API capabilities” certification criteria proposed in § 170.315(j)</FP>
                    <FP SOURCE="FP-1">• support for dynamic registration and subsequent authentication and authorization of patient-facing, user-facing, and system confidential apps</FP>
                    <FP SOURCE="FP-1">• support for multi-factor authentication for patient-facing authentication according to requirements proposed in § 170.315(d)(13)(ii)</FP>
                    <FP SOURCE="FP-1">• support for imaging links in data response requirements</FP>
                    <FP SOURCE="FP-1">• support for a read and search API for system apps</FP>
                    <FP SOURCE="FP-1">• support for “_type” query parameter for Bulk FHIR API</FP>
                    <FP SOURCE="FP-1">• support for the issuance of verifiable health records as specified by the requirements proposed in § 170.315(j)(22)</FP>
                    <FP SOURCE="FP-1">• support for subscriptions as a server according to the requirements specified in proposed § 170.315(j)(23)</FP>
                    <FP SOURCE="FP-1">• support for workflow triggers for decision support interventions according to the requirements specified in proposed § 170.315(j)(20)</FP>
                    <FP SOURCE="FP-1">
                        • support for authorization revocation for users (
                        <E T="03">e.g.,</E>
                         clinicians)
                    </FP>
                    <FP SOURCE="FP-1">• moving of the API documentation requirements in § 170.315(g)(10) to the API Conditions and Maintenance of Certification requirements in § 170.404</FP>
                    <P>We propose that by January 1, 2028, a health IT developer of a Health IT Module certified to the criterion in § 170.315(g)(10) must update its Health IT Module and provide the updated version to its customers in order to maintain certification of that Health IT Module. We propose that any Health IT Modules seeking certification for the criterion in § 170.315(g)(10) on or after January 1, 2028, would be to the updated version of the certification criterion.</P>
                    <HD SOURCE="HD3">xx. Patient, Provider, and Payer APIs</HD>
                    <P>
                        The combined exchange of clinical and administrative data among healthcare payers, patients, and providers is a complex challenge that can prevent participants in the healthcare system from gaining insights into the full picture of an individual's care. In order to realize the benefits of a more unified stream of clinical and administrative data, patients and health care providers must be able to more efficiently access and exchange EHI with the entities that steward this information, especially healthcare payers. In the CMS Interoperability and Patient Access Final Rule (85 FR 25510), which appeared in the 
                        <E T="04">Federal Register</E>
                         on May 1, 2020, and the CMS Interoperability and Prior Authorization Final Rule (89 FR 8758), which appeared in the 
                        <E T="04">Federal Register</E>
                         on February 8, 2024, CMS finalized policies for certain healthcare payers that it regulates 
                        <SU>14</SU>
                        <FTREF/>
                         to facilitate patient access to clinical and administrative data held by payers; availability of information about provider networks; exchange of information between payers when beneficiaries patients change coverage; provider access to data held by payers; and electronic prior authorization.
                    </P>
                    <FTNT>
                        <P>
                            <SU>14</SU>
                             The “impacted payers” under the CMS Interoperability and Patient Access Final Rule (85 FR 25510) and the CMS Interoperability and Prior Authorization Final Rule (89 FR 8758) are Medicare Advantage (MA) organizations, state Medicaid fee-for-service (FFS) programs, state Children's Health Insurance Program (CHIP) FFS programs, Medicaid managed care plans, CHIP managed care entities, and Qualified Health Plan (QHP) issuers on the Federally-facilitated Exchanges (FFEs).
                        </P>
                    </FTNT>
                    <P>
                        As explained in section III.B.20, we propose a set of certification criteria in § 170.315(g)(30) through (36) that aim to complement and advance the policies that CMS has developed to increase patient, provider, and payer access to information. Health IT developers, including those that support payers, would be able to ensure that Health IT Modules certified to these proposed criteria, when used to satisfy the CMS requirements, have been tested for conformance with widely available industry standards designed to support interoperability for each use case. We propose to adopt a set of HL7® FHIR® IGs in § 170.215 to support these certification criteria, and to incorporate these specifications by reference in § 170.299.
                        <PRTPAGE P="63507"/>
                    </P>
                    <HD SOURCE="HD3">2. Conditions and Maintenance of Certification Requirements—Insights and Attestations</HD>
                    <HD SOURCE="HD3">a. Insights Condition and Maintenance of Certification Requirements</HD>
                    <P>As discussed in section III.C.1, we propose to update the Insights Condition by requiring health IT developers to include health care provider identifiers, for providers included in the data submitted in response for the measures specified in § 170.407, to allow us to better interpret the results of the data received. We also propose updates to the overall process for reporting and newer versions of certified health IT for responses submitted under the Insights Condition in § 170.407(b).</P>
                    <P>We also propose to update two measures under the Insights Condition. We propose to revise the “individuals' access to electronic health information through certified health IT” measure in § 170.407(a)(3)(i) to include both individuals and individuals' authorized representatives accessing their EHI. Additionally, we propose to revise the name of the measure in § 170.407(a)(3)(ii) to “C-CDA reconciliation and incorporation through certified health IT” and propose to require developers to submit responses on specific data classes and elements from C-CDA documents reconciled and incorporated both through manual and automated processes in § 170.407(a)(3)(ii)(E). We also intend to make various technical updates to the measure specification sheets accompanying the Insights Condition, including the clarification of certain definitions and terms, as well as adding new metrics.</P>
                    <HD SOURCE="HD3">b. Attestations Condition and Maintenance of Certification Requirements</HD>
                    <P>As discussed in section III.C.2, we propose to revise the Attestations Condition and Maintenance of Certification requirements by adding the requirement in § 170.406(a)(2) that a health IT developer, as a Condition of Certification, attest to compliance with § 170.402(b)(4), if the health IT developer certified a Health IT Module(s) to the “decision support interventions” certification criteria in § 170.315(b)(11).</P>
                    <HD SOURCE="HD3">3. Administrative Updates</HD>
                    <P>As discussed in section III.D.1, we propose to revise the Program correspondence provision (§ 170.505) to explicitly specify when applicants for ONC-Authorized Testing Laboratory (ATL) status, applicants for ONC-ACB status, ONC-ACBs, ONC-ATLs, health IT developers or any other party to a proceeding under subpart E of 45 CFR part 170 will be considered to have received correspondence or other written communication from ONC or the National Coordinator.</P>
                    <P>As discussed in section III.D.2, we propose to expand ONC-ACBs responsibilities under § 170.556 for conducting surveillance of developers' satisfaction of certain Maintenance of Certification requirements under the Program. We also propose new and revised principles of proper conduct (PoPCs) in § 170.523 to support the proposed expanded surveillance responsibilities. Specifically, an ONC-ACB would be required to monitor Program-participating developers' satisfaction of specific requirements applicable to the developers under subpart D of 45 CFR part 170, report results of these surveillance activities to ONC, and engage with developers where applicable to encourage corrective action for identified non-conformities. A new proposed PoPC in § 170.523(x), pursuant to a new proposed requirement in § 170.556(d)(7)(ii), would require ONC-ACBs to report to ONC when a developer fails to establish or to successfully complete an appropriate corrective action plan (CAP) for a Maintenance of Certification non-conformity identified by an ONC-ACB.</P>
                    <P>To increase efficiency for developers' documentation of their CAPs, and ONC-ACBs' review and monitoring of these plans, we propose in § 170.556(d)(3) to tailor the minimum required CAP elements based on the non-conformities addressed by the CAP. For example, certain CAP elements designed for non-conformities with certification criteria in 45 CFR subpart C would not be required by regulation in a CAP specific to a developer having missed a deadline in subpart D, such as for submission of real world testing documents (§ 170.405) or submission of attestations (§ 170.406).</P>
                    <P>As discussed in section III.D.3, we propose a requirement in § 170.523(m)(6) for ONC-ACBs, beginning January 1, 2027, to obtain a regular reporting of API discovery details, including service base URLs and related organization details, that are required by § 170.404(b)(2) and (b)(3). In section III.D.4, we propose a new PoPC for ONC-ACBs in § 170.523(y) requiring an ONC-ACB to give the National Coordinator sufficient notice of its intent to withdraw its authorization under the Program.</P>
                    <P>In section III.D.5, we discuss our proposal to update the ONC direct review regulatory framework in 45 CFR 170.580 to align with the proposed enhancements to the ONC-ACBs' role in surveillance of Program-participating developers' satisfaction of certain Maintenance of Certification requirements. To enhance efficiency for developers and ONC, we propose to revise direct review CAP regulatory requirements to add flexibility to tailor the minimum elements the developer must address in such a plan for a non-conformity substantiated through an ONC direct review. We also propose procedural revisions to § 170.581, suspension and termination of certification procedures in § 170.580(d) and (f), and hearing officer and appeals provisions in § 170.580(g)(5) and (7)(ii), to clarify that certain “ONC” decisions are in fact made by the National Coordinator, and explicitly provide for the Secretary to choose to exercise direct oversight of certain National Coordinator and hearing officer decisions before the decisions become final. We also propose to revise wording throughout 45 CFR 170.580 and 45 CFR 170.581 to clarify that certain determinations are made by the National Coordinator (who is appointed by the Secretary) rather than more generally by or within the Office of the National Coordinator (the organizational unit headed by the National Coordinator).</P>
                    <P>As discussed in section III.D.6, we propose to update paragraphs (a) and (b) of the certification ban provisions in § 170.581 to explicitly provide for the Secretary to review, at the Secretary's discretion, the National Coordinator's determination to impose a certification ban before the ban becomes effective. In section III.D.7, we propose to remove the “Complete EHR” and “EHR Module” terms from certain sections within subpart E of 45 CFR part 170.</P>
                    <P>
                        As discussed in section III.D.8, we propose to codify a definition of 
                        <E T="03">serious risk to public health or safety</E>
                         for purposes of Program regulations in 45 CFR part 170. This definition would enhance understanding among developers and users of certified health IT of the types of conditions, events, or phenomena that would constitute a dangerous non-conformity to Program requirements if caused (or contributed to) by a product certified under the Program, even if the Health IT Modules within such product continued to pass lab testing procedures, in-the-field surveillance testing, or both with respect to the technical standards and certification criteria adopted in subparts B and C of part 170. As discussed in section III.D.9, we propose to remove § 170.550(m) “time-limited certification and certification status for certain 2015 Edition certification criteria” and to 
                        <PRTPAGE P="63508"/>
                        remove certification criteria with time-limited certification and certification status, including § 170.315(a)(10), (a)(13), (b)(6), (e)(2), and (g)(8). Additionally, as discussed in section III.D.9, we propose to revise § 170.315(b)(7) and (b)(8) to remove § 170.315(b)(7)(ii) and (b)(8)(i)(B), which were time-limited provisions (now expired) that permitted health IT to demonstrate security tagging of Consolidated-Clinical Document Architecture (C-CDA) documents at the document level. In section III.D.10, we propose to revise § 170.550(h), the Privacy and Security Certification Framework requirements by adding the certification criterion “decision support interventions” in § 170.315(b)(11) to the list of certification criteria in § 170.550(h)(3)(ii).
                    </P>
                    <HD SOURCE="HD3">4. Correction—Privacy and Security Certification Framework</HD>
                    <P>We propose to make a correction to the Privacy and Security Certification Framework in § 170.550(h), as discussed in section III.E. We revised § 170.550(h) in the ONC Cures Act Final Rule but intended for § 170.550(h)(4) to remain unchanged. However, when we drafted the amendatory instructions, we erroneously included the instruction to revise all of paragraph (h) (85 FR 25952). Therefore, when the Code of Federal Regulations was updated, § 170.550(h)(4) was removed. We now propose to add the § 170.550(h)(4) that existed prior to the ONC Cures Act Final Rule being finalized.</P>
                    <HD SOURCE="HD3">5. Information Blocking Enhancements</HD>
                    <P>
                        In this rule, we propose revisions to defined terms for purposes of the information blocking regulations, which appear in 45 CFR 171.102. We propose to revise three existing exceptions in subpart B of 45 CFR part 171 and solicit comment on potential revisions to one exception in subpart D. We propose two new exceptions, one in each in subparts B and C of part 171. We propose to codify in § 171.401 definitions of certain terms relevant to the Trusted Exchange Framework and Common Agreement
                        <SU>TM</SU>
                         (TEFCA
                        <SU>TM</SU>
                        ) and in § 171.104 descriptions of certain practices that constitute interference with the access, exchange, and use of electronic health information (EHI).
                    </P>
                    <P>As discussed in section IV.A.1, we propose to amend the definition of “health care provider,” codified in 45 CFR 171.10,2 so that it is explicitly clear that it references 42 U.S.C. 300jj(3) and that for purposes of this definition the terms “laboratory” and “pharmacist” have the meanings established for these terms in 42 U.S.C. 300jj(10) and (12), respectively. In IV.A.2, we propose that for purposes of the information blocking regulations in 45 CFR part 171 both “health information technology” and its shorter form, “health IT,” have the same meaning as “health information technology” in 42 U.S.C. 300jj(5).</P>
                    <P>For purposes of the information blocking definition (§ 171.103), the term “interfere with or interference” is currently defined in § 171.102. Informed by the concerns and questions that interested parties have brought to our attention, we propose in section IV.A.3 to add a section (§ 171.104) to the information blocking regulations that would codify certain practices (acts and omissions) that constitute interferences for purposes of the information blocking definition (codified in § 171.103). The proposed codified practices are not an exhaustive list; additional practices not described in the proposed § 171.104 that are likely to interfere with, prevent, or materially discourage access, exchange, or use of EHI may also be considered to rise to the level of an interference. The proposed codification of these specific practices is intended to provide actors, and those who seek to engage in EHI access, exchange, or use with actors, certainty that these specific practices constitute interference. The codification of these practices may also help regulated entities and other interested parties to consider the likelihood that any practice an actor might contemplate or engage in may also meet the definition of “interference” and “interfere with” (as defined in § 171.102) for purposes of the information blocking regulations (45 CFR part 171).</P>
                    <P>For purposes of the information blocking Privacy Exception, the term “individual” is defined in § 171.202(a)(2). As currently worded, this text includes cross-references to incorrect citations within § 171.202(a)(2). The text also includes one unnecessary cross-reference citation within § 171.202(a)(2). We do not propose to change the substance of the definition, but in section IV.B.1.a, we propose technical corrections to the cross-reference citations within § 171.202(a)(2)(iii), (iv), and (v).</P>
                    <P>In section IV.B.1.b, to clearly establish coverage of the § 171.202(d) sub-exception for all actors' practices under the same requirements, we propose to change the name of the sub-exception to: “interfering with individual access based on unreviewable grounds.” This proposed change to the header text is intended to express the expansion of its availability to actors who are not Health Insurance Portability and Accountability Act of 1996 (HIPAA) covered entities or business associates (as defined in 45 CFR 160.103). As explained in section IV.B.1.c, we propose to slightly modify the header of § 171.202(e) for ease of reference to “Individual's request not to share EHI.” More importantly, we propose to revise the § 171.202(e) sub-exception to remove the existing limitation that allows the exception to be used only for individual-requested restrictions on EHI sharing that are permitted by other applicable law. The proposal would extend the availability of the § 171.202(e) sub-exception to an actor's practice of applying restrictions the individual has requested on the access, exchange, or use of an individual's EHI even when the actor may have concern that another law applicable to some or all of the actor's operations could compel the actor to provide access, exchange, or use of EHI contrary to the individual's expressed wishes.</P>
                    <P>
                        We propose, as discussed in section IV.B.2, revisions to three conditions of the Infeasibility Exception (45 CFR 171.204). Specifically, we propose to modify the § 171.204(a)(2) 
                        <E T="03">segmentation</E>
                         condition to enhance clarity and certainty, and to provide for its application to additional specific situations. We propose to revise the condition to specifically cross-reference additional information blocking exceptions under which an actor may choose to withhold EHI that the actor could, under applicable law, make available.
                    </P>
                    <P>
                        We propose to modify the § 171.204(a)(3) 
                        <E T="03">third party seeking modification use</E>
                         condition by changing the words “health care provider” to “covered entity as defined in 45 CFR 160.103” in the exclusion from applicability of this condition. We also propose in § 171.204(a)(3)(ii) to extend the exclusion from applicability of the 
                        <E T="03">third party seeking modification use</E>
                         condition requests for modification use from health care providers, as defined in § 171.102 and who are not covered entities, requesting such use from actors whose activities would make them a business associate of that same health care provider if the healthcare provider (actor) was covered by HIPAA.
                    </P>
                    <P>
                        We propose to modify the § 171.204(b) 
                        <E T="03">responding to requests</E>
                         condition by establishing different timeframes for sending written responses to the requestor based on the § 171.204(a) condition under which fulfilling the requested access, exchange, or use of EHI is infeasible. The proposed revision would retain the requirement that actors communicate to requestors “in writing the reason(s) why the request is infeasible” that we 
                        <PRTPAGE P="63509"/>
                        finalized in the ONC Cures Act Final Rule. We discuss these proposals further in sections IV.B.2.a through c of this proposed rule.
                    </P>
                    <P>In section IV.B.3, we propose a new Protecting Care Access Exception that would, under specified conditions (see sections IV.B.3.b through d and the draft regulatory text of proposed § 171.206), apply to acts or omissions likely to interfere with access, exchange, or use of particular EHI that an actor believes could create a risk of exposing patients, care providers, and other persons who assist in access or delivery of health care to potential administrative, civil, or criminal investigations or other actions on certain bases. A summary of these bases follows below in this section. (Please see section IV.B.3 of this proposed rule for detailed discussion.)</P>
                    <P>The proposed Protecting Care Access Exception (§ 171.206) would be a new exception in addition to the other information blocking exceptions. The proposed new exception is designed to create certainty for actors that certain practices for which no other exception would apply will not be considered “information blocking” under the information blocking statute (PHSA section 3022) and regulations (45 CFR part 171). Like any existing or proposed information blocking exception in 45 CFR part 171, the proposed Protecting Care Access Exception (§ 171.206) is not intended to override any provision of another law that is independently applicable to the actor.</P>
                    <P>The practices that the proposed Protecting Care Access Exception (§ 171.206) would except from the information blocking definition would be those implemented based on the actor's good faith belief that sharing EHI indicating that any person(s) sought, received, provided, or facilitated the provision or receipt of reproductive health care that was lawful under the circumstances in which it was provided could result in a risk of potential exposure to legal action for those persons and that the risk could be reduced by practices likely to interfere with particular access, exchange, or use of specific EHI. For purposes of the Protecting Care Access Exception, we propose to rely on the same definition of “reproductive health care” (which can be found in 45 CFR 160.103) that is used for purposes of the HIPAA regulations. In addition, we discuss in section IV.B.3.b how we would interpret whether care is “lawful under the circumstances in which it is provided.”</P>
                    <P>To satisfy the proposed new Protecting Care Access (§ 171.206) Exception, an actor's practice would need to satisfy the threshold condition (§ 171.206(a)), and at least one of the other two conditions in the exception: the patient protection condition (§ 171.206(b)) or the care access condition (§ 171.206(c)). The combination of conditions required to satisfy the proposed new Protecting Care Access Exception and the definition of “legal action” (in § 171.206(d)) for purposes of the exception would, together, ensure that the exception would not apply to an actor's attempts to shield any person from legal action based on allegations that health care items or services the person provided are substandard.</P>
                    <P>These provisions together would also ensure that the exception focuses on the specific situation where an actor limits the sharing of EHI because the actor believes it could result in a risk of potentially exposing the patient or another person to an investigation or other civil, criminal, or administrative action based on the mere fact that the person sought, obtained, provided, or facilitated reproductive health care that was lawful under the circumstances in which it was provided. For instance, the exception would not apply to an actor's attempt to interfere with EHI sharing in order to reduce a patient's or other person's risk of exposure to a criminal investigation or charges not related to the act of seeking, obtaining, providing, or facilitating reproductive health care. For example, the act of not sharing information because of the risk of a criminal investigation related to operating a vehicle while intoxicated or committing fraud would not be covered under this exception.</P>
                    <P>The Protecting Care Access Exception's threshold condition (§ 171.206(a)), proposed in section IV.B.3.b, includes requirements that the practice be: undertaken based on the actor's belief as specified in § 171.206(a)(1), no broader than necessary as specified in § 171.206(a)(2), and be implemented consistent with a written organizational policy or case-by-case determination contemporaneously documented in writing as specified in § 171.206(a)(3). Meeting the threshold condition would be necessary, but not alone sufficient, for an actor's practice to be covered by the proposed Protecting Care Access (§ 171.206) exception. To satisfy the exception, any actor's practice likely to interfere with access, exchange, or use of EHI would also need to satisfy at least one of the other two conditions (in paragraphs (b) and (c)) of the proposed exception.</P>
                    <P>In section IV.B.3.c, we propose a patient protection condition (§ 171.206(b)), that can be met by practices implemented by the actor for the purpose of reducing a risk of potential legal action that the actor believes a patient could otherwise face because the EHI shows or invites a reasonable inference that the patient has or has done any of the following (see proposed § 171.206(b)(1)):</P>
                    <P>(i) obtained reproductive health care that was lawful under the circumstances in which it was provided;</P>
                    <P>(ii) Inquired about or expressed an interest in seeking reproductive health care; or</P>
                    <P>(iii) Particular demographic characteristics or any health condition(s) or history for which reproductive health care is often sought, obtained, or medically indicated.</P>
                    <P>
                        The proposed patient protection condition would specify (§ 171.206(b)(2)) that to meet the condition the actor's practice must be subject to nullification by explicit request or directive from the patient. We also clarify (in proposed § 171.206(b)(3)) that for purposes of the patient protection condition's other paragraphs that “patient” means the natural person who is the subject of the EHI or another natural person referenced in, or identifiable from, the EHI as having sought or received reproductive health care.
                        <SU>15</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>15</SU>
                             The definition of “person” for purposes of 45 CFR part 171 is codified in § 171.102 and is, by cross-reference to 45 CFR 160.103, the same definition used for purposes of the HIPAA Privacy Rule (45 CFR part 160 and subpart E of 45 CFR part 164). The § 160.103 definition of “person” clarifies the meaning of “natural person” within it. We use “natural person” in this proposed rule with that same meaning.
                        </P>
                    </FTNT>
                    <P>In section IV.B.3.d, we propose a care access condition (§ 171.206(c)) that can be met by practices an actor might choose to implement for the purpose of reducing a risk of potential exposure to legal action for licensed health care professionals, other health care providers, or persons involved in providing or in facilitating the provision or receipt of reproductive health care that is lawful under the circumstances in which such health care is provided. We request comment on multiple, potentially non-exclusive, alternative proposals for additional requirements under the care access condition that would function to restrict the exception's coverage of practices that interfere with access, exchange, or use in scenarios that also implicate the HIPAA Privacy Rule's individual right of access provisions (45 CFR 164.524). In order to satisfy this proposed condition, if finalized, the practice would need to meet the requirements finalized in § 171.206(c).</P>
                    <P>
                        We propose clarifying provisions in § 171.206(d) (discussed in section 
                        <PRTPAGE P="63510"/>
                        IV.B.3.b of this proposed rule) and § 171.206(e) (discussed in section IV.B.3.e of this proposed rule). Proposed § 171.206(d) would clarify when reproductive health care sought, obtained, provided, or facilitated by someone other than the actor will be presumed to have been lawful for purposes of assessing whether an actor's practice meets the exception's patient protection or care access condition. In § 171.206(e) we propose to define “legal action” for purposes of § 171.206. We propose in section IV.B.4, a new information blocking exception: “Requestor Preferences” in 45 CFR 171.304. This exception would stand separate from and independent of other exceptions and would apply where an actor honors or adheres to a requestor's preference(s) expressed or confirmed in writing for: (1) limitations on the amount of EHI made available to the requestor; (2) the conditions under which EHI is made available to the requestor; and (3) when EHI is made available to the requestor for access, exchange, or use. The exception would offer an actor certainty that, so long as the actor's practices meet the conditions of the exception, the actor can honor or adhere to a requestor's preferences related to these specific preferences without concern that the actor may be engaging in “information blocking” as defined in 45 CFR 171.103.
                    </P>
                    <P>We propose to add a new definitions section in § 171.401 for certain terms used in Subpart D, which we propose to align with the definitions used in the proposed 45 CFR 172. We seek comment on some aspects of the TEFCA Manner Exception in 45 CFR 171.403, including the limitation on its use for requests made via a FHIR API and the application of the Fees and Licensing Exceptions to practices that satisfy the exception.</P>
                    <HD SOURCE="HD3">
                        6. Trusted Exchange Framework and Common Agreement
                        <SU>TM</SU>
                    </HD>
                    <P>
                        Section 3001(c)(9) of PHSA, as added by the 21st Century Cures Act (Pub. L. 114-255, Dec. 13, 2016) (Cures Act), calls for the development or support of a “trusted exchange framework, including a common agreement among health information networks nationally.” On January 19, 2022, ONC published in the 
                        <E T="04">Federal Register</E>
                         the Notice of Publication of the Trusted Exchange Framework and Common Agreement (87 FR 2800), in which ONC published the Trusted Exchange Framework (TEF): Principles for Trusted Exchange and the Common Agreement for Nationwide Health Information Interoperability Version 1. ONC published in the 
                        <E T="04">Federal Register</E>
                         a notice titled Trusted Exchange Framework and Common Agreement Version 1.1 on November 7, 2023 (88 FR 76773), in which ONC published the Common Agreement for Nationwide Health Information Interoperability Version 1.1 (November 2023), and published version 2.0 implementing the latest industry standards among other changes on May 1, 2024 (89 FR 35107). Section 3001(c)(9)(A) of the PHSA states that the overall goal for TEFCA
                        <SU>TM</SU>
                         is to ensure full network-to-network exchange of health information. ONC intends to accomplish this by establishing a floor for interoperability under TEFCA across the country. The Common Agreement 
                        <SU>16</SU>
                        <FTREF/>
                         is authorized by section 3001(c)(9)(B)(i) of the statute, which addresses: baseline legal and technical requirements for the Common Agreement, organizational and operational policies to enable exchange, minimum conditions for exchange, and a process for filing and adjudicating noncompliance with its terms. The Common Agreement addresses all of these to enable users in different health information networks (HINs) to securely share information with each other—all under commonly agreed-to expectations and terms. The Trusted Exchange Framework,
                        <SU>17</SU>
                        <FTREF/>
                         authorized under the same provision of the PHSA, describes a common set of principles for policies and practices to facilitate data-sharing.
                    </P>
                    <FTNT>
                        <P>
                            <SU>16</SU>
                             Common Agreement for Nationwide Health Information Interoperability, Version 1.1 (November 2023), 
                            <E T="03">available at</E>
                              
                            <E T="04">Federal Register</E>
                            :: Trusted Exchange Framework and Common Agreement Version 1.1.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>17</SU>
                             The Trusted Exchange Framework (TEF): Principles for Trusted Exchange (January 2022), 
                            <E T="03">available at https://www.healthit.gov/sites/default/files/page/2022-01/Trusted_Exchange_Framework_0122.pdf.</E>
                        </P>
                    </FTNT>
                    <P>
                        The Recognized Coordinating Entity® (RCE
                        <SU>TM</SU>
                        ) is an ONC contractor that is charged with helping ONC to develop, operationalize, and update the Common Agreement, as well as assist ONC in stewarding the Qualified Health Information Network
                        <SU>TM</SU>
                         (QHIN
                        <SU>TM</SU>
                        ) Technical Framework (QTF),
                        <SU>18</SU>
                        <FTREF/>
                         which provides the technical specifications for how QHINs connect to one another. The RCE also helps ONC to oversee QHIN-facilitated network operations and QHIN compliance with the Common Agreement.
                    </P>
                    <FTNT>
                        <P>
                            <SU>18</SU>
                             Qualified Health Information Network (QHIN) Technical Framework, Version 1.0 (January 2022), 
                            <E T="03">available at https://rce.sequoiaproject.org/wp-content/uploads/2022/01/QTF_0122.pdf.</E>
                        </P>
                    </FTNT>
                    <P>
                        As explained in the proposed part 172 of subchapter D of title 45 of the Code of Federal Regulations, by standardizing health information exchange across many different networks, TEFCA will help to ensure full network-to-network exchange of health information. Doing so will simplify exchange by significantly reducing the number of connections (
                        <E T="03">e.g.,</E>
                         portals) that individuals, health care providers, and other interested parties need to make to get the health information they seek. It does so by creating baseline governance, legal, and technical requirements that will enable secure information sharing across different networks nationwide, including: a common method for authenticating trusted network participants, a common set of rules for trusted exchange, organizational and operational policies to enable the exchange of health information among networks, and a process for filing and adjudicating noncompliance with the terms of the Common Agreement. As explained in proposed part 172, we believe that TEFCA will help lower the cost and expand the nationwide availability of secure health information exchange capabilities. The availability of TEFCA-based services, such as electronic address directories and patient record location, will also help scale health information exchange nationwide and usher in new support for FHIR API usage and adoption. FHIR API usage and adoption has become a centerpiece of the interoperability initiatives of ONC and other U.S. government agencies such as CDC,
                        <SU>19</SU>
                        <FTREF/>
                         CMS,
                        <SU>20</SU>
                        <FTREF/>
                         Health Resources and Services Administration (HRSA),
                        <SU>21</SU>
                        <FTREF/>
                         and the Veteran's Administration (VA).
                        <SU>22</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>19</SU>
                             
                            <E T="03">See</E>
                             CDC, Public Health Informatics Office (PHIO), 
                            <E T="03">https://www.cdc.gov/csels/phio/it_takes_practice.html.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>20</SU>
                             
                            <E T="03">See</E>
                             CMS, Policies and Technology for Interoperability and Burden Reduction, 
                            <E T="03">https://www.cms.gov/policies-and-technology-interoperability-and-burden-reduction.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>21</SU>
                             
                            <E T="03">See</E>
                             HRSA, Uniform Data System (UDS) Modernization Initiative, 
                            <E T="03">https://bphc.hrsa.gov/data-reporting/uds-training-and-technical-assistance/uniform-data-system-uds-modernization-initiative.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>22</SU>
                             
                            <E T="03">See</E>
                             VA, VA Technical Reference Model v 23.12, 
                            <E T="03">https://www.oit.va.gov/Services/TRM/StandardPage.aspx?tid=8233.</E>
                        </P>
                    </FTNT>
                    <P>
                        In section V of this proposed rule, we propose to implement certain provisions related to TEFCA in order to provide greater process transparency and further implement section 3001(c)(9) of the PHSA, as added by the Cures Act. We propose to add a new part, part 172, to subchapter D of title 45 of the Code of Federal Regulations to implement certain provisions related to the TEFCA. These proposed provisions would establish the processes associated with the qualifications necessary for an entity to receive and maintain Designation (as we propose to define that term in § 172.102) as a QHIN capable of trusted exchange under the Common 
                        <PRTPAGE P="63511"/>
                        Agreement. The proposals would also establish the procedures governing Onboarding (as we propose to define that term in § 172.102) of QHINs and Designation of QHINs, suspension, termination, and administrative appeals to ONC, as described in the sections below. We believe establishing these provisions in regulation would support reliability, privacy, security, and trust within TEFCA, which would further TEFCA's ultimate success.
                    </P>
                    <P>In subpart A, we propose the statutory basis, purpose, and scope of the TEFCA provisions in part 172; the applicability of the TEFCA provisions in part 172; and relevant definitions. In subpart B, we propose requirements related to the qualifications needed to be Designated, as proposed to be defined in § 172.102. In subpart C, we describe the proposed QHIN Onboarding and Designation processes. In subpart D, we propose RCE and QHIN suspension rights, notice requirements for suspension, and the requirements related to the effect of suspension. In subpart E, we propose RCE and QHIN termination rights, notice requirements for termination, and requirements related to the effect of termination. In subpart F, we propose to establish QHIN appeal rights and the process for filing an appeal to ONC. These appeal rights would ensure that a QHIN, or Applicant QHIN, that (1) disagrees with certain RCE determinations or (2) believes an action or inaction by a QHIN or the RCE could threaten TEFCA's integrity will have recourse to appeal such determination, action, or inaction to ONC.</P>
                    <P>In subpart G, we propose requirements related to QHIN attestation for the Adoption of TEFCA. This subpart implements section 3001(c)(9)(D) of the PHSA. Section 3001(c)(9)(D)(i) requires the publication on ONC's website of those HINs that have adopted the Common Agreement and are capable of trusted exchange pursuant to the Common Agreement. Section 3001(c)(9)(D)(ii) requires HHS to establish, through notice and comment rulemaking, a process for HINs that voluntarily elect to adopt TEFCA to attest to such adoption.</P>
                    <HD SOURCE="HD2">C. Severability</HD>
                    <P>It is our intent that if any provision of this rule were, if or when finalized, held to be invalid or unenforceable facially, or as applied to any person, plaintiff, or stayed pending further judicial or agency action, such provision shall be severable from other provisions of this rule, and from rules and regulations currently in effect, and not affect the remainder of this rule. It is also our intent that, unless such provision shall be held to be utterly invalid or unenforceable, it be construed to give the provision maximum effect permitted by law including in the application of the provision to other persons not similarly situated or to other, dissimilar circumstances from those where the provision may be held to be invalid or unenforceable.</P>
                    <P>In this rule, we propose provisions that are intended to and will operate independently of each other, even if multiple of them serve the same or similar general purpose(s) or policy goal(s). Where a provision is necessarily dependent on another, the context generally makes that clear (such as by cross-reference to a particular standard, requirement, condition, or pre-requisite). Where a provision that is dependent on one that is stayed or held invalid or unenforceable (as described in the preceding paragraph) is included in a subparagraph, paragraph, or section within part 170, 171, or 172 of 45 CFR, we intend that other provisions of such subparagraph(s), paragraph(s), or section(s) that operate independently of said provision would remain in effect.</P>
                    <P>To ensure our intent for severability of provisions is clear in the CFR, we propose to add to existing § 170.101 and § 171.101, and to include in the proposed new § 172.101 a paragraph stating our intent that if any provision is held to be invalid or unenforceable it shall be construed to give maximum effect to the provision permitted by law, unless such holding shall be one of utter invalidity or unenforceability, in which case the provision shall be severable from this part and shall not affect the remainder thereof or the application of the provision to other persons not similarly situated or to other dissimilar circumstances.</P>
                    <HD SOURCE="HD2">D. Costs and Benefits</HD>
                    <P>
                        Executive Orders 12866 and 13563 direct agencies to assess all costs and benefits of available regulatory alternatives and, if regulation is necessary, to select regulatory approaches that maximize net benefits (including potential economic, environmental, public health and safety effects, distributive impacts, and equity). Executive Order 14094 entitled “Modernizing Regulatory Review” (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 proposed rule is a significant regulatory action, as the potential economic impacts associated with this proposed 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 proposed rule. We have estimated the potential monetary costs and benefits of this proposed rule for the health IT community, including costs and benefits as they relate to health IT developers, health care providers, patients, and the Federal Government (
                        <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 82.
                    </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>23</SU>
                        <FTREF/>
                         We also note that estimates presented in sections titled “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” are used throughout this RIA.
                    </P>
                    <FTNT>
                        <P>
                            <SU>23</SU>
                             May 2022 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 proposed rule for the first year 
                        <PRTPAGE P="63512"/>
                        after it is finalized (including one-time costs), based on the cost estimates outlined above and throughout this RIA, would result in $431.1 million. The total undiscounted perpetual cost over a 10-year period for this proposed rule (starting in year two), based on the cost estimates outlined above, would result in $398.1 million. We estimate the total costs to health IT developers to be $829.2 million.
                    </P>
                    <P>We estimate the total annual benefit across all entities for this proposed rule beginning in Year 3, when the associated policies are required to be implemented and expected benefits to be realized, would be on average $22.2 million. We estimate the total benefits across all entities to be $177.6 million. We estimate the total undiscounted perpetual annual net benefit for this proposed rule (starting in year three), based on the estimates outlined above, would result in a net benefit of $75.4 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 EHI exchange.</P>
                    <P>The 21st Century Cures Act (Pub. L. 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 sponsors of prescription drug plans to implement one or more real-time benefit tools (RTBTs) that meet the requirements described in the statute, after the Secretary has adopted a standard for RTBTs and at a time determined appropriate by the Secretary. For purposes of the requirement to implement a real-time benefit tool in section 1860D-4(o)(1) of the Social Security Act, described above, the CAA provides that one of the 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 ONC Health IT Certification Program (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 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. ONC Health IT Certification Program Rules</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 
                        <PRTPAGE P="63513"/>
                        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”) 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>
                        . Section 3001(c)(9)(D)(i) requires the National Coordinator to publish a list of HINs that have adopted TEFCA. Section 3001(c)(9)(D)(ii) requires the Secretary to establish a process for HINs to attest that they have adopted TEFCA.
                    </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; application programming interfaces (APIs); real world testing; attestations regarding certain conditions and maintenance of certification requirements; and submission of reporting criteria under the EHR Reporting Program in accordance with section 3009A(b) of the PHSA.</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 Program, a history of which can be found in the October 16, 2015 final rule “2015 Edition Health Information (Health IT) Certification Criteria, 2015 Edition Base Electronic Health Record (EHR) Definition, and ONC Health IT Certification Program Modifications” (80 FR 62602) (2015 Edition Final Rule). The history can be found at 80 FR 62606. A final rule making corrections and clarifications 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 EHR Technology (CEHRT) would need to include to support the achievement of “meaningful use” by eligible clinicians, eligible hospitals, and critical access hospitals under the Medicare and Medicaid EHR Incentive Programs (EHR Incentive Programs) (now referred to as the Promoting Interoperability Programs and the Promoting Interoperability performance category under MIPS) when the 2015 Edition is required for use under these and other programs referencing the CEHRT definition. The final rule also adopted a proposal to change the Program's name to the “ONC Health IT Certification Program” from the ONC HIT Certification Program, modified the Program to make it more accessible to other types of health IT beyond EHR technology and for health IT that supports care and practice settings beyond the ambulatory and inpatient settings, and adopted new and revised Principles of Proper Conduct (PoPC) for ONC-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 final rule created a regulatory framework for our direct review of health IT certified under the Program, including, when necessary, requiring the correction of non-conformities found in health IT certified under the Program and suspending and terminating certifications issued to Complete EHRs and Health IT Modules. The final rule also set forth processes for us to authorize and oversee accredited testing laboratories under the Program. In addition, it included provisions for expanded public availability of certified health IT surveillance results.</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 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 
                        <PRTPAGE P="63514"/>
                        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 final rule implemented certain provisions of the Cures Act, including Conditions and Maintenance of Certification requirements for health IT developers, the voluntary certification of health IT for use by pediatric health providers, and reasonable and necessary activities that do not constitute information blocking. The final rule also implemented certain parts of the Cures Act to support patients' access to their EHI, and the implementation of information blocking policies that support patient electronic access. Additionally, the final rule modified the 2015 Edition health IT certification criteria and Program in other ways to advance interoperability, enhance health IT certification, and reduce burden and costs, as well as improving patient and health care provider access to EHI and promoting competition. On November 4, 2020, the Secretary published an interim final rule with comment period titled, “Information Blocking and the ONC Health IT Certification Program: Extension of Compliance Dates and Timeframes in Response to the COVID-19 Public Health Emergency” (85 FR 70064) (Cures Act Interim Final Rule). The interim final rule extended certain compliance dates and timeframes adopted in the ONC Cures Act Final Rule to offer the healthcare system additional flexibilities in furnishing services to combat the COVID-19 pandemic, including extending the applicability date for information blocking provisions to April 5, 2021.</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” (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 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 to make several updates to certification criteria and implementation specifications recognized by the Program, including revised certification criterion for: “clinical decision support” (CDS), “patient demographics and observations”, and “electronic case reporting.” The HTI-1 Proposed Rule also proposed to establish a new baseline version of the United States Core Data for Interoperability (USCDI). Additionally, the HTI-1 Proposed Rule proposed enhancements to support information sharing under the information blocking regulations.</P>
                    <P>On January 9, 2024, the Secretary issued the “Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing” final rule (HTI-1 Final Rule), which implemented the EHR Reporting Program provision of the 21st Century Cures Act and established new Conditions and Maintenance of Certification requirements for health IT developers under the Program (89 FR 1192). The HTI-1 Final Rule also made several updates to certification criteria and standards recognized by the Program. The Program updates included revised certification criteria for “decision support interventions,” “patient demographics and observations,” and “electronic case reporting,” as well as adopted a new baseline version of the USCDI standard, USCDI Version 3. Additionally, the HTI-1 Final Rule provided enhancements to support information sharing under the information blocking regulations. Through these provisions, we sought to advance interoperability, improve algorithm transparency, and support the access, exchange, and use of EHI. The HTI-1 Final Rule also updated 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>
                    <P>On November 15, 2023, the Secretary issued a proposed rule titled, “Medicare Program; Contract Year 2025 Policy and Technical Changes to the Medicare Advantage Program, Medicare Prescription Drug Benefit Program, Medicare Cost Plan Program, and Programs of All-Inclusive Care for the Elderly; Health Information Technology Standards and Implementation Specifications” (88 FR 78476). This proposed rule proposed to adopt the National Council for Prescription Drug Programs (NCPDP) Real-Time Prescription Benefit standard version 13.</P>
                    <P>On June 17, 2024, the Secretary issued the Part D and Health IT Standards final rule (89 FR 51238 through 51265). This final rule adopted the NCPDP Real-Time Prescription Benefit standard version 13 in 45 CFR 170.205(c)(1) and to incorporate this standard by reference in 45 CFR 170.299. In this final rule, CMS also adopted requirements for Part D sponsors to use the standard in in 45 CFR 170.205(c)(1) when implementing an RTBT.</P>
                    <HD SOURCE="HD1">III. ONC Health IT Certification Program Updates</HD>
                    <HD SOURCE="HD2">A. Standards and Implementations 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>24</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. In this proposed rule, we use voluntary consensus standards except for:
                    </P>
                    <FTNT>
                        <P>
                            <SU>24</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>
                        • The USCDI v4 standard. We propose to adopt USCDI v4 in § 170.213. This standard 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);
                    </P>
                    <P>
                        • The Federal Information Processing Standard (140-2) related to the 
                        <PRTPAGE P="63515"/>
                        protection of electronic health information adopted in § 170.210;
                    </P>
                    <P>• The CMS standards for QRDA I and III respectively adopted in § 170.205(h)(2) and (k)(3).</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 proposed rule, including for establishing a baseline set of data that can be commonly exchanged across care settings for a wide range of uses. We refer readers to section III.B.1 of this preamble for a discussion of the USCDI.</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. For example, if we adopted the SMART Application Launch Framework Implementation Guide Release 2.2 (SMART v2.2) proposed in this proposed rule (see section III.B.2), health IT certified to certification criteria referencing this IG would need to demonstrate compliance with all mandatory elements and requirements of the IG. If an element of the IG is optional or permissive in any way, it would remain that way for testing and certification unless we specified otherwise in regulation. In such cases, the regulatory text would supersede 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(a)). To comply with these requirements, in section VI (“Incorporation by Reference”) of this preamble, we provide summaries of, and uniform resource locators (URLs) to, the standards and implementation specifications we propose to adopt 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 the proposed rule.
                    </P>
                    <HD SOURCE="HD2">B. New and Revised Standards and Certification Criteria</HD>
                    <HD SOURCE="HD3">1. The United States Core Data for Interoperability Version 4 (USCDI v4)</HD>
                    <HD SOURCE="HD3">a. Background and USCDI v4 Update</HD>
                    <P>
                        The United States Core Data for Interoperability (USCDI) is a standardized set of health data classes and data elements for the sharing of electronic health information.
                        <SU>25</SU>
                        <FTREF/>
                         We established USCDI as a standard in the ONC Cures Act Final Rule (85 FR 25670), adopting USCDI Version 1 (USCDI v1) in § 170.213 and incorporating it by reference in § 170.299.
                        <SU>26</SU>
                        <FTREF/>
                         In a final rule titled “Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing” (HTI-1 Final Rule) and published on January 9, 2024, we adopted USCDI Version 3 (USCDI v3) in § 170.213 and incorporated it by reference in § 170.299 (89 FR 1210 through 1223).
                    </P>
                    <FTNT>
                        <P>
                            <SU>25</SU>
                             
                            <E T="03">https://www.healthit.gov/isa/united-states-core-data-interoperability-uscdi.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>26</SU>
                             
                            <E T="03">https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-D/part-170#p-170.213.</E>
                        </P>
                    </FTNT>
                    <P>
                        The USCDI standard in § 170.213 is a baseline set of data that can be commonly exchanged across care settings for a wide range of uses. Certain certification criteria in § 170.315 currently require the use of one of the versions of the USCDI standard in § 170.213. USCDI is also referenced by HHS programs and used by the healthcare community to align interoperability requirements and national priorities for health IT across industry initiatives. For the overall structure and organization of USCDI, including data classes and data elements, please see 
                        <E T="03">www.healthIT.gov/USCDI.</E>
                    </P>
                    <P>
                        As described in the ONC Cures Act Final Rule, we use a predictable, transparent, and collaborative process to expand the USCDI standard, including providing the opportunity for public comment (85 FR 25670). Additionally, as described in the ONC Cures Act Final Rule, health IT developers can use the Standards Version Advancement Process (SVAP) to voluntarily implement and use the most recent National Coordinator-approved version of USCDI without waiting for ONC to require that newer version via rulemaking (85 FR 25669). ONC uses a public comment process to identify newer versions of standards for approval by the National Coordinator as part of SVAP.
                        <SU>27</SU>
                        <FTREF/>
                         USCDI v3 was available for voluntary implementation through SVAP as of September 2023.
                    </P>
                    <FTNT>
                        <P>
                            <SU>27</SU>
                             
                            <E T="03">https://www.healthit.gov/isa/standards-version-advancement-process.</E>
                        </P>
                    </FTNT>
                    <P>Based on feedback ONC received through the ONC New Data Element and Class submission system, ONC identified a set of data elements and data classes for a draft version of USCDI v4, which was released in January 2023. The draft version of USCDI v4 included 20 new data elements and one new data class as well as updates to minimum standard code set versions. ONC then finalized and released USCDI v4 in July 2023.</P>
                    <P>
                        We propose to update the USCDI standard in § 170.213 by adding USCDI v4. We propose that for purposes of the Program, the adoption of USCDI v3 expires on January 1, 2028. We propose to add USCDI v4 in § 170.213(c) and incorporate it by reference in § 170.299. We propose that as of January 1, 2028, any Health IT Modules seeking certification to criteria referencing § 170.213 would need to be capable of exchanging the data elements that the USCDI v4 comprises. The additional data elements in USCDI v4 reflect many of the recommendations expressed by the Health IT Advisory Committee in their report to the National Coordinator.
                        <SU>28</SU>
                        <FTREF/>
                         As finalized in the HTI-1 Final Rule, 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 (89 FR 1215). This proposed rule would advance the USCDI standard to USCDI v4, continuing ONC's commitment to a transparent and predictable schedule for health IT developers with respect to updates to the USCDI's regulatory baseline. If finalized, this proposal would provide significant clarity and certainty to health IT developers who would have substantial time to update certified health IT to support USCDI v4.
                    </P>
                    <FTNT>
                        <P>
                            <SU>28</SU>
                             
                            <E T="03">https://www.healthit.gov/sites/default/files/page/2023-05/2023-04-12_IS_WG_USCDI_v4_Transmittal_Letter_508.pdf.</E>
                        </P>
                    </FTNT>
                    <P>
                        For certification to a criterion in § 170.315 that references the USCDI standard adopted in § 170.213, we propose that a Health IT Module must use at least one of the versions of the USCDI standard that is (1) adopted in § 170.213 or approved by SVAP at the time the Health IT Module seeks certification and (2) not expired at the time of use. When a Health IT Module certified to a criterion in § 170.315 that references the USCDI standard adopted in § 170.213 is using a version with an 
                        <PRTPAGE P="63516"/>
                        upcoming expiration date or is using an interim version approved by SVAP, we propose that the health IT developer must update the Module to either a new version of the standard adopted in § 170.213 or a subsequent version approved by SVAP prior to the expiration date or dates defined in order to maintain certification of that Health IT Module as described in § 170.315. Consistent with the health IT developer must provide the updated Health IT Module to their customers by the expiration date or dates defined in order to maintain certification of that Health IT Module as described in § 170.315. We describe these proposals further in section III.B.1.b below.
                    </P>
                    <HD SOURCE="HD3">b. Certification Criteria That Reference USCDI</HD>
                    <P>The USCDI standard is currently cross-referenced in certain certification criteria (see § 170.213). A Health IT Module can be certified to any of these criteria by ensuring that it complies with any unexpired version of the USCDI included in § 170.213 or a version of the USCDI standard that is approved through SVAP at the time the Health IT Module seeks certification. The certification criteria that currently cross-reference to USCDI via § 170.213 are as follows:</P>
                    <P>
                        • “Care coordination—Transitions of care—Create” (§ 170.315(b)(1)(iii)(A)(
                        <E T="03">1</E>
                        ) and (
                        <E T="03">2</E>
                        ));
                    </P>
                    <P>
                        • “Care coordination—Clinical information reconciliation and incorporation—Reconciliation” (§ 170.315(b)(2)(iii)(D)(
                        <E T="03">1)</E>
                        -(
                        <E T="03">3</E>
                        ));
                    </P>
                    <P>
                        • “Decision support interventions—Decision support configuration” (§ 170.315(b)(11)(ii)(A) and (B), and (iv)(A)(
                        <E T="03">5</E>
                        )-(
                        <E T="03">13</E>
                        )));
                    </P>
                    <P>
                        • “Patient engagement—View, download, and transmit to 3rd party—View” (§ 170.315(e)(1)(i)(A)(
                        <E T="03">1</E>
                        ) and (
                        <E T="03">2</E>
                        ), and (iii));
                    </P>
                    <P>
                        • “Transmission to public health agencies—electronic case reporting” (§ 170.315(f)(5)(i)(C)(
                        <E T="03">2</E>
                        )(
                        <E T="03">i</E>
                        ));
                    </P>
                    <P>• “Design and performance—Consolidated CDA creation performance” (§ 170.315(g)(6)(i)(A) and (B));</P>
                    <P>
                        • “Design and performance—Application access—all data request—Functional requirements” (§ 170.315(g)(9)(i)(A)(
                        <E T="03">1</E>
                        ) and (
                        <E T="03">2</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 propose that up to and including December 31, 2027, a Health IT Module certified to criteria referencing § 170.213 may use either USCDI v3 or USCDI v4. We propose that by January 1, 2028, a health IT developer of a Health IT Module certified to criteria referencing § 170.213 must update to USCDI v4 and provide the updated version to their customers in order to maintain certification of that Health IT Module. We also note that if these proposals are finalized, for any time before January 1, 2026, USCDI v1 could still be used to meet the applicable certification criteria as well (see 89 FR 1211 through 1223).</P>
                    <P>Further, we propose that Health IT Modules certified to certification criteria that reference § 170.213 would need to update their Health IT Modules to accommodate USCDI v4 data elements using the FHIR® US Core Implementation Guide Version 7.0.0 proposed in § 170.215(b)(1)(iii) and the HL7 CDA R2 Implementation Guide: Consolidated CDA Templates for Clinical Notes, Edition 3—US Realm, proposed in § 170.205(a)(1). We also propose that adoption of the standards in § 170.205(a)(6) and § 170.215(b)(1)(ii) expire on January 1, 2028. As stated in the HTI-1 Final Rule, our intent would be to adopt the version of these standards necessary for developers of certified health IT to have appropriate implementation guidance to meet the certification criteria that reference USCDI v4, and these updated implementation guides best align with and support effective implementation of USCDI v4. Based on public comments on HTI-1 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 89 FR 1215).</P>
                    <HD SOURCE="HD3">2. SMART App Launch 2.2</HD>
                    <P>In the ONC HTI-1 Final Rule, we adopted the HL7® FHIR® SMART Application Launch Framework Implementation Guide Release 2.0.0 (SMART v2 Guide), a profile of the OAuth 2.0 specification, in § 170.215(c)(2) (89 FR 1291 through 1295). Public comments received during the HTI-1 rulemaking process indicated near universal support for the adoption of the SMART v2 Guide, with the caveat that several of these commenters suggested we adopt the newest balloted version of the SMART App Launch IG, which at the time of the HTI-1 public comment period was version 2.1. We declined to adopt the newest balloted version of the SMART App Launch IG in the HTI-1 Final Rule, noting that the SMART v2 Guide had “already been an established part of the Program via SVAP and rigorously tested . . .” (89 FR 1292). However, we also noted that “[w]e will consider potential ways the SMART v2.1 IG could be included in the Program in the future . . .” (89 FR 1292).</P>
                    <P>We note that current ONC policy as established in the ONC Cures Act Final Rule (85 FR 25741) and reiterated in the HTI-1 Final Rule (89 FR 1293) is that as part of supporting the SMART App Launch “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. Furthermore, we finalized in the HTI-1 Final Rule (89 FR 1294) that as part of supporting the SMART App Launch “permission-v2” capability Health IT Modules must support certain sub-resource scopes for the Condition and Observation resources. Specifically, we established minimal conformance requirements at the category level for the Condition and Observation resources using specifications and guidance from the SMART v2 Guide and FHIR US Core 6.1.0 implementation guides to ensure that Health IT Modules required to support the SMART v2 Guide 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>In this proposed rule, we clarify the existing Program requirements to support patient authorization using SMART App Launch capabilities. Specifically, we clarify that if both the “permission-patient” and “permission-v2” capabilities are required in support of patient authorization for certification to a criterion in the Program, then a Health IT Module must support the following:</P>
                    <P>• Support for the ability for patients to authorize an application to receive their EHI based on individual FHIR resource-level and individual sub-resource-level scopes.</P>
                    <P>• Support for the ability for patients to authorize an application to receive their EHI based on individual sub-resource-level scopes when corresponding resource-level scopes are requested.</P>
                    <P>
                        These requirements enable patients to have the ability to authorize access to their EHI at a more granular level in alignment with required SMART App Launch authorization capabilities. The capabilities enabled by these requirements empower patients with authorization ability at the individual sub-resource level, and the ability to provide granular authorization at the 
                        <PRTPAGE P="63517"/>
                        individual sub-resource level even if the authorization request from the app is made at the resource level. We note that both the “permission-patient” and “permission-v2” capabilities are required as part of the “Permissions” subsection of the SMART App Launch IGs proposed in § 170.215(c)(2) and § 170.215(c)(3). We propose “Permissions” in § 170.315(j)(9), which is cross-referenced in § 170.315(g)(10) and § 170.315(g)(30) in this proposed rule. We anticipate that future certification criteria will also include “permission-patient” and “permission-v2” support requirements to support of patient authorization and we intend for this clarification to support patient authorization of individual sub-resource level scopes to also apply.
                    </P>
                    <P>Specific guidance and requirements regarding the implementation of resource and sub-resource scopes are included in the US Core 7.0.0 implementation guide. We clarify for the purposes of certification under the Program, support for the US Core IG includes supporting all SMART App Launch scope requirements included in the US Core IG, including requirements to support resource and sub-resource scopes.</P>
                    <P>
                        We note throughout this rule we propose revisions to existing API certification criteria and propose new API certification criteria wherein specificity in the requirements regarding the properties of applications is important. To provide a consistent and industry standard definition of app types referenced in Program API certification criteria, we clarify that “confidential app,” “public app,” and “native app” as referenced in this rule and in Program API requirements refers to “confidential client,” “public client,” and “native application” respectively as defined in internet Engineering Task Force (IETF) Request for Comments (RFC) 6749 “The OAuth 2.0 Authorization Framework.” 
                        <SU>29</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>29</SU>
                             IETF RFC 6749 “The OAuth 2.0 Authorization Framework” available here: 
                            <E T="03">https://datatracker.ietf.org/doc/rfc6749/.</E>
                        </P>
                    </FTNT>
                    <P>The SMART Application Launch Framework Implementation Guide, Release 2.2 (SMART v2.2 Guide), published at the end of April 2024, is the most recent version available at the time of this proposed rule. The SMART v2.2 Guide includes features that iterate on the features of the SMART v2 Guide, including the enhancements from the SMART v2.1 Guide and the latest industry consensus updates.</P>
                    <P>
                        Notable enhancements in the SMART v2.2 Guide include a more detailed and standardized “fhirContext” parameter, including the ability for servers to include optional “roles” for offering a detailed description of included resource references in the “fhirContext” parameter; updates to the “fhirUser” context parameter to allow the use of the “PractitionerRole” resource for representing the current user authorizing the launch; and clarification regarding the “exp” field in the token introspection response, ensuring consistency between the “exp” field in the token introspection response and the “expires_in” interval in the original access token response. Additionally, to eliminate ambiguity in URL resolution, the SMART v2.2 Guide mandates the use of absolute URLs in the Well-Known configuration file, disallowing relative URLs. The SMART v2.2 Guide also introduces a new Cross-Origin Resource Sharing (CORS) security requirement applicable to servers supporting purely browser-based apps. Finally, an important new addition to the SMART v2.2 Guide is the User-Access Brands and Endpoints (Brands) specification, which allows API providers to publish Brands associated with their FHIR Endpoints to enable apps to collect and present these Brands to users (
                        <E T="03">e.g.,</E>
                         patients).
                    </P>
                    <P>Overall, these enhancements to the SMART v2.2 Guide improve standardization and provide clarity to help support consistent implementation and improve interoperability. We welcome comment on our assessment of these SMART v2.2 Guide changes.</P>
                    <P>Based on HTI-1 public comment feedback and to make use of the new Brands specification in the Program, we propose to adopt the SMART v2.2 Guide in § 170.215(c)(3) and incorporate it by reference as a subparagraph in § 170.299. Additionally, we propose that the adoption of the SMART v2 Guide in § 170.215(c)(2) would expire on January 1, 2028. If we finalize these proposals, developers of certified health IT with Health IT Modules certified to criteria referencing the implementation specifications in § 170.215(c) may use the SMART v1, SMART v2, or SMART v2.2 Guides for the time period up to and including December 31, 2025. Then by January 1, 2026, when the adoption of SMART v1 expires, developers of certified health IT with Health IT Modules certified to criteria referencing the implementation specifications in § 170.215(c) must update to the SMART v2 or SMART v2.2 Guides and provide the updated version to their customers in order to maintain certification of that Health IT Module. Finally, by January 1, 2028, when the adoption of the SMART v2 Guide expires, developers of certified health IT with Health IT Modules certified to criteria referencing the implementation specifications in § 170.215(c) must update to the SMART v2.2 Guide and provide the updated health IT module to their customers in order to maintain certification of that Health IT Module. We propose that any Health IT Modules seeking certification to criteria referencing the implementation specifications in § 170.215(c) on or after January 1, 2028, would need to be capable of supporting the SMART v2.2 Guide.</P>
                    <P>Our proposal to require health IT developers participating in the program to update and provide to customers Health IT Modules updated to according to the timelines for the implementation specifications in § 170.215(c) includes all certification criteria that reference the implementation specifications in § 170.215(c) directly, or via reference to our proposed modular API capabilities certification criteria in § 170.315(j)(6), (j)(7), (j)(8), (j)(9), and (j)(10) that also reference the implementation specifications in § 170.215(c). In this proposed rule these certification criteria are: § 170.315(g)(10), (g)(20), (g)(30), (g)(32), (g)(33), (g)(34), and (g)(35). We note that § 170.315(g)(20), (g)(30), (g)(32), (g)(33), (g)(34), and (g)(35) are new Program certification criteria proposed in this rule and the only currently finalized certification criterion in the Program that includes a reference to § 170.215(c) is § 170.315(g)(10).</P>
                    <P>
                        To reference the SMART Guide across these proposed new and revised certification criteria, we propose to move the SMART Guide component references (
                        <E T="03">e.g.,</E>
                         specific capabilities and sections) out of the subparagraphs in § 170.215(c), so that only entire SMART Guide references are listed under § 170.215(c). This will enable the SMART Guides to be referenced across Program certification criteria, whilst also enabling references to specific SMART Guide components tailored to the requirements of a specific certification criterion. For example, the proposed § 170.315(j)(9) certification criterion as proposed in the section titled “New Certification Criteria for Modular API Capabilities” would reference § 170.215(c) along with a list of applicable SMART Guide components tailored specifically to describe SMART Guide requirements for patient authorization for standalone apps.
                    </P>
                    <P>
                        We note that later versions of the SMART Guide may be finalized by the time of our final rule. During the time between our proposed rule and our final rule, the FHIR community may, for example, issue technical corrections in a SMART v2.2.x Guide or release a 
                        <PRTPAGE P="63518"/>
                        newer SMART v2.x Guide minor release. We intend to evaluate and potentially adopt in the final rule the most recent available version of the SMART Guide that aligns with the SMART v2.2 Guide changes outlined in this proposed rule. We encourage interested parties to monitor the SMART App Launch IG directory of published versions (
                        <E T="03">https://hl7.org/fhir/smart-app-launch/history.html</E>
                        ) for all IG iterations, technical corrections, and releases. We welcome comment on this proposal.
                    </P>
                    <HD SOURCE="HD3">3. User-Access Brands and Endpoints</HD>
                    <P>
                        In the ONC HTI-1 Final Rule, we finalized requirements in § 170.404(b)(2) for Certified API Developers to publish certain service base URLs and related organization (
                        <E T="03">i.e.,</E>
                         API Information Source) details in a standardized FHIR® format (89 FR 1285 through 1290). Public comments received during the HTI-1 rulemaking process indicated strong support for the “continued development and standardization of publication formats for FHIR `service base URLs' ” (89 FR 1286). Many of these commenters suggested we adopt a FHIR implementation guide, with a particular emphasis on the Patient-access Brands (PAB) specification. We declined to adopt PAB or any other FHIR implementation guides for § 170.404(b)(2) at the time, and instead finalized more generalized base FHIR requirements to best ensure compatibility with the emerging industry FHIR implementation guides. Given the particular interest in the PAB specification we noted in HTI-1 that “[w]e will consider the Patient-access Brands specification for adoption in future rulemaking as it develops” (89 FR 1288).
                    </P>
                    <P>
                        Currently, the PAB specification, now referred to as “User-access Brands and Endpoints,” (and referred to as Brands herein) is set for publication as a sub-specification in the SMART v2.2 Guide. The Brands specification “defines FHIR profiles for Endpoint, Organization and Bundle resources that help users connect their apps to health data providers.” 
                        <SU>30</SU>
                        <FTREF/>
                         It provides guidelines for API providers to publish Brands associated with their FHIR endpoints that apps can collect and present to users. Each Brand can include information like organization name, location, identifiers, patient portal details, FHIR API Endpoints, and more. These Brands are assembled in FHIR “Bundle” format, and these Bundles can made available in two ways: by FHIR servers including a link in their SMART “.well-known/smart-configuration” 
                        <SU>31</SU>
                        <FTREF/>
                         metadata file, or through vendor-consolidated Brand Bundles that are openly published.
                    </P>
                    <FTNT>
                        <P>
                            <SU>30</SU>
                             
                            <E T="03">https://hl7.org/fhir/smart-app-launch/STU2.2/brands.html.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>31</SU>
                             
                            <E T="03">https://hl7.org/fhir/smart-app-launch/STU2.2/brands.html#metadata-in-well-knownsmart-configuration.</E>
                        </P>
                    </FTNT>
                    <P>We propose to update our current maintenance of certification (MoC) requirements in § 170.404(b)(2) that reference FHIR resources and elements directly and adopt Brands in § 170.404(b)(2)(iii) as a replacement. Specifically, we propose to reorganize the regulation text paragraphs in a way that places existing service base URL requirements into § 170.404(b)(2)(ii) that expire on December 31, 2027. We propose in our updated § 170.404(b)(2)(iii) to require that, by January 1, 2028, service base URLs and related API Information Source details, including each organization's name, location, and facility identifier, must be published in an aggregate vendor-consolidated “FHIR Bundle” according to the Brands specification. Additionally, we propose to move our existing publication terms and quarterly review and update requirements, that we have currently finalized in § 170.404(b)(2) and (b)(2)(iii)(B), to subparagraphs under § 170.404(b)(2)(i) that apply broadly to other sub-paragraphs under § 170.404(b)(2), including our new proposed Brands requirements in § 170.404(b)(2)(iii). Finally, we propose that a health IT developer may meet the proposed revised MoC requirements by satisfying the new conformance requirements proposed in § 170.404(b)(2)(i), (iii), and (iv) in lieu of § 170.404(b)(2)(i) and (ii) prior to December 31, 2027.</P>
                    <P>
                        We believe that our proposed changes to § 170.404(b)(2) logically build on our existing MoC requirements in § 170.404(b)(2) because the Brands specification uses profiles of the same base FHIR resources (
                        <E T="03">i.e.,</E>
                         “Endpoint,” “Organization,” and “Bundle”) we have finalized in § 170.404(b)(2). Requiring the use of the more standardized FHIR profiles in Brands that are designed specifically for the endpoint publication use case reduces inconsistent and varied implementations leading to increased interoperability. We also believe that our proposed changes to § 170.404(b)(2) align with much of the public feedback we received during the HTI-1 rulemaking process where the Brands precursor PAB specification was cited numerous times (89 FR 1286 through 1289). We welcome comment on this proposal to reference Brands for publication of service base URLs and related organization details in § 170.404(b)(2).
                    </P>
                    <P>Additionally, in our revised § 170.404(b)(3) where we propose new requirements for the publication of API discovery details for payer network information, including service base URLs and API Information source details, we propose to adopt Brands specification. Please see section III.B.20.d for further details on proposed § 170.404 updates.</P>
                    <P>We note that the Brands specification is a sub-specification in the SMART v2.2 Guide and we anticipate that subsequent versions of Brands will be included in subsequent versions of the SMART Guide. We also note that our proposed January 1, 2028 date for the SMART v2.2 Guide to be the minimum version in § 170.215(c) (see section III.B.2 for our proposal to adopt the SMART v.2.2 Guide in § 170.215(c)) matches the date that health IT developers subject to the requirements in § 170.404(b)(2) must support Brands for publication of API discovery details for patient access.</P>
                    <P>
                        As we noted in section III.B.2, later versions of the SMART Guide may be finalized by the time of our final rule. This includes changes to the Brands specification, or potential corrections if identified, and we intend to evaluate and potentially adopt in the final rule the most recent available version of the SMART Guide if doing so would best support interoperability and effective program implementation. We encourage interested parties to monitor the SMART App Launch IG directory of published versions (
                        <E T="03">https://hl7.org/fhir/smart-app-launch/history.html</E>
                        ) for all IG iterations, technical corrections, and releases. We welcome comment on this proposal.
                    </P>
                    <HD SOURCE="HD3">4. Standards for Encryption and Decryption of Electronic Health Information</HD>
                    <HD SOURCE="HD3">a. Background</HD>
                    <P>In the 2015 Edition Final Rule, ONC adopted the October 8, 2014, version of Annex A: Approved Security Functions for Federal Information Processing Standards (FIPS) Publication 140-2. This October 8, 2014, version was the most recent version published by the National Institute of Standards and Technology (NIST) when the 2015 Edition Final Rule published (80 FR 62707).</P>
                    <HD SOURCE="HD3">b. Proposal</HD>
                    <P>
                        Since finalizing the October 8, 2014, version of Annex A: Approved Security Functions for FIPS Publication 140-2 standard in the 2015 Edition Final Rule, 
                        <PRTPAGE P="63519"/>
                        encryption techniques and security best practices have continued to advance, and NIST has published several updated versions of Annex A: Approved Security Functions for FIPS Publication 140-2.
                        <SU>32</SU>
                        <FTREF/>
                         The most recent version of Annex A for FIPS Publication 140-2 is Draft, October 12, 2021. We propose to adopt the Draft, October 12, 2021, version of Annex A for FIPS Publication 140-2 in § 170.210(a)(3) and incorporate it by reference as a subparagraph in § 170.299. We also propose that the adoption of the FIPS 140-2 October 8, 2014, version in § 170.210(a)(2) expire on January 1, 2026. We note that the FIPS 140-2 October 8, 2014, version was inadvertently removed from § 170.299, therefore we propose to incorporate by reference the standard in § 170.299(m)(3). We welcome comment on these proposals.
                    </P>
                    <FTNT>
                        <P>
                            <SU>32</SU>
                             
                            <E T="03">See</E>
                             pages 4-6 of the October 12, 2021 version of Annex A for a revision history of the standard. Available at: 
                            <E T="03">https://csrc.nist.gov/csrc/media/publications/fips/140/2/final/documents/fips1402annexa.pdf.</E>
                        </P>
                    </FTNT>
                    <P>We note that revising § 170.210(a) would implicate three certification criteria that reference standards in § 170.210(a):</P>
                    <P>• § 170.315(d)(7) End-user device encryption, which we propose to revise and rename as “Health IT encryption” elsewhere in this preamble;</P>
                    <P>• § 170.315(d)(9) Trusted connection; and</P>
                    <P>• § 170.315(d)(12) Encrypt authentication credentials, which we propose to further revise and rename as “Protect stored authentication credentials” elsewhere in this preamble.</P>
                    <P>Given the cross reference to § 170.210(a)(2) in these certification criteria, we propose to revise each certification criterion in § 170.315(d)(7), (d)(9), and (d)(12) to replace “standard” with “at least one version of the standard” and “§ 170.210(a)(2)” with “§ 170.210(a)” where appropriate in each certification criterion. At revised § 170.315(d)(7)(iv) we propose to revise both “standard” and “§ 170.210(a)(2)” in this manner. In § 170.315(d)(9)(i) and (ii); and at revised § 170.315(d)(12)(i)(A), we also propose to revise “standard” and “§ 170.210(a)(2)” in this manner. As noted, we describe our remaining proposed revisions to § 170.315(d)(7) and § 170.315(d)(12) elsewhere in this preamble at III.B.11 and III.B.12 and we invite readers to review those sections.</P>
                    <P>Additionally, we propose to remove the standard found in § 170.210(f) that is no longer referenced in any active certification criteria. We welcome comments on our proposals.</P>
                    <P>
                        Finally, we solicit comment on the transition to the next FIPS standard, FIPS 140-3, that is currently underway.
                        <SU>33</SU>
                        <FTREF/>
                         We are monitoring development in this area, and we welcome comment on FIPS 140-3 and any potential impacts to our Program requirements. We note that Annex A for FIPS 140-2 is compatible with current FIPS 140-3 guidance as an “Approved Security Function,” and we intend to re-evaluate the latest FIPS 140-3 guidance at the time of the final rule to ensure continued capability with FIPS 140-3.
                        <SU>34</SU>
                        <FTREF/>
                         We recognize the potential for changes in FIPS 140-2 and 140-3 by the time of our final rule. Therefore, we intend to consider and potentially finalize the most recent Approved Security Functions that align with current FIPS guidance at the time and that are compatible with the Annex A for FIPS 140-2 update we are proposing in this proposed rule. We welcome comment on this proposal.
                    </P>
                    <FTNT>
                        <P>
                            <SU>33</SU>
                             
                            <E T="03">See</E>
                             FIPS 140-3 Transition Effort page—
                            <E T="03">https://csrc.nist.gov/projects/fips-140-3-transition-effort.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>34</SU>
                             The “10. Approved Security Functions” requirements in FIPS 140-3 (March 22, 2019 version) state that “Approved security functions include those that are . . . adopted in a FIPS and specified either in an appendix to the FIPS or in a document referenced by the FIPS.” The October 12, 2021 draft version of Annex A for FIPS 140-2 meets that criterion to contain “Approved Security Functions” according to FIPS 140-3. 
                            <E T="03">See https://csrc.nist.gov/pubs/fips/140-3/final.</E>
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">5. 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 the final rule entitled “Health Information Technology: Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology, 2014 Edition; Revisions to the Permanent Certification Program for Health Information Technology” (77 FR 54163) 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). As we stated in the HTI-1 Final Rule, 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 (89 FR 1224). 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.</P>
                    <P>For certification to a criterion in § 170.315 that references the standard adopted in § 170.207, we propose that a Health IT Module must use at least one of the versions of the standard that is (1) adopted in § 170.207 or approved by SVAP at the time the Health IT Module seeks certification and (2) not expired at the time of use. We also propose that when a Health IT Module certified to a criterion in § 170.315 that references the standard adopted in § 170.207 is using a version with an upcoming expiration date or is using an interim version approved by SVAP, the health IT developer must update the Module to either a new version of the standard adopted in § 170.207, or a subsequent version approved by SVAP, prior to the expiration date or dates defined in order to maintain certification of that Health IT Module as described in § 170.207. In addition, the health IT developer must provide the updated Health IT Module to their customers by the expiration date or dates defined in § 170.207 in order to maintain certification of that Health IT Module as described in § 170.315.</P>
                    <FP SOURCE="FP-1">• § 170.207(a)—Problems</FP>
                    <P>We propose to revise § 170.207(a)(2), which is currently reserved, to reference SNOMED CT®, U.S. Edition, September 2023 Release and incorporate it by reference in § 170.299. We also propose that the adoption of the standard in § 170.207(a)(1), SNOMED CT, U.S. Edition, March 2022 Release, would expire on January 1, 2028, and that the adoption of the standard in § 170.207(a)(4), IHTSDO SNOMED CT, U.S. Edition, September 2015 Release, would expire on January 1, 2026.</P>
                    <FP SOURCE="FP-1">• § 170.207(c)—Laboratory tests</FP>
                    <P>We propose to revise § 170.207(c)(2) to reference Logical Observation Identifiers Names and Codes (LOINC®) Database version 2.76, a universal code system for identifying laboratory and clinical observations produced by the Regenstrief Institute, Inc. and incorporate it by reference in § 170.299. We also propose that the adoption of the standard in § 170.207(c)(1), LOINC Database Version 2.72, would expire on January 1, 2028, and that the adoption of the standard in § 170.207(c)(3), LOINC Database version 2.52, would expire on January 1, 2026.</P>
                    <FP SOURCE="FP-1">• § 170.207(d)—Medications</FP>
                    <P>
                        We propose to revise the citations in § 170.207(d) to improve organization of 
                        <PRTPAGE P="63520"/>
                        this section. Specifically, we propose to revise § 170.207(d)(1) to list standards for clinical drugs and to reference multiple releases of RxNorm, a standardized nomenclature for clinical drugs produced by the United States National Library of Medicine. We propose in § 170.207(d)(1)(ii) to reference RxNorm, December 4, 2023 Full Monthly Release and incorporate it by reference in § 170.299. We propose to move the standard adopted in § 170.207(d)(1), RxNorm, July 5, 2022 Release, to § 170.207(d)(1)(i), and that the adoption of this standard would expire on January 1, 2028. We propose to move the standard adopted in § 170.207(d)(3), RxNorm, September 8, 2015 Release, to § 170.207(d)(1)(iii) and that the adoption of this standard would expire on January 1, 2026. Finally, we propose to move National Drug Codes, currently included via cross-reference in § 170.207(d)(4), to § 170.207(d)(2). We note that § 170.207(d)(2) is currently reserved. We also propose to reserve § 170.207(d)(3) and remove § 170.207(d)(4).
                    </P>
                    <FP SOURCE="FP-1">• § 170.207(e)—Immunizations</FP>
                    <P>We propose to reference in § 170.207(e)(5) the CDC National Center of Immunization and Respiratory Diseases (NCIRD) Code Set (CVX)—Vaccines Administered, updates through September 29, 2023, and incorporate it by reference in § 170.299. We also propose to reference in § 170.207(e)(6) the National Drug Code (NDC)—Vaccine NDC Linker, updates through November 6, 2023, and incorporate it by reference in § 170.299. We propose that adoption of the standards in § 170.207(e)(1), the HL7® Standard Code Set CVX—Vaccines Administered, dated through June 15, 2022, and § 170.207 (e)(2), NDC—Vaccine NDC Linker, dated July 19, 2022, would expire on January 1, 2028. We also propose that adoption of the standards in § 170.207(e)(3), HL7 Standard Code Set CVX—Vaccines Administered, updates through August 17, 2015, and § 170.207(e)(4), NDC—Vaccine NDC Linker, updates through August 17, 2015, would expire on January 1, 2026.</P>
                    <FP SOURCE="FP-1">• § 170.207(f)—Race and Ethnicity</FP>
                    <P>We propose to revise § 170.207(f)(1) to include recent updates to the U.S. Office of Management and Budget's Statistical Policy Directive No. 15: Standards for Maintaining, Collecting, and Presenting Federal Data on Race and Ethnicity (SPD 15). In § 170.207(f)(1)(i) we propose to include The Office of Management and Budget Standards for Maintaining, Collecting, and Presenting Federal Data on Race and Ethnicity, Statistical Policy Directive No. 15, as revised, October 30, 1997 with an expiration date of January 1, 2026 for adoption of that standard. In § 170.207(f)(1)(ii) we propose to include the U.S. Office of Management and Budget's Statistical Policy Directive No. 15: Standards for Maintaining, Collecting, and Presenting Federal Data on Race and Ethnicity (SPD 15), as revised, March 29, 2024.</P>
                    <P>We propose to revise § 170.207(f)(2) to include CDC Race and Ethnicity Code Set standards. In § 170.207(f)(2)(i) we propose to include CDC Race and Ethnicity Code Set Version 1.0 (March 2000) with an expiration of January 1, 2026, for adoption of that standard. In § 170.207(f)(2)(ii) we propose to include CDC Race and Ethnicity Code Set Version 1.2 (July 08, 2021) and incorporate it by reference in § 170.299. We propose to remove and reserve § 170.207(f)(3).</P>
                    <FP SOURCE="FP-1">• § 170.207(m)—Numerical references</FP>
                    <P>We propose that adoption of the standard in § 170.207(m)(1), The Unified Code of Units of Measure, Revision 1.9, would expire on January 1, 2026.</P>
                    <FP SOURCE="FP-1">• § 170.207(n)—Sex</FP>
                    <P>We propose that adoption of the standard in § 170.207(n)(1), HL7 Version 3 Standard, Value Sets for AdministrativeGender and NullFlavor, would expire on January 1, 2026. We propose to revise § 170.207(n)(2) to reference use of at least one of the versions of SNOMED CT U.S. Edition specified in § 170.207(a). We also propose to revise § 170.207(n)(3) to reference use of at least one of the versions of LOINC specified in § 170.207(c).</P>
                    <FP SOURCE="FP-1">• § 170.207(o)—Sexual orientation and gender information</FP>
                    <P>We propose to revise § 170.207(o)(1)-(3) to reference use of at least one of the versions of SNOMED CT U.S. Edition specified in § 170.207(a) instead of § 170.207(a)(4). We also propose to revise § 170.207(o)(4) to reference use of at least one of the versions of LOINC specified in § 170.207(c).</P>
                    <FP SOURCE="FP-1">• § 170.207(p)—Social, psychological, and behavioral data</FP>
                    <P>We propose to revise § 170.207(p)(1) through (8) to reference use of at least one of the versions of LOINC specified in § 170.207(c).</P>
                    <P>We propose to revise § 170.207(p)(4), (5), (6), (7), and (8) to reference use of at least one of the versions of the standard specified in § 170.207(m).</P>
                    <FP SOURCE="FP-1">• § 170.207(r)—Provider type</FP>
                    <P>We propose that adoption of the standard in § 170.207(r)(1) would expire on January 1, 2026.</P>
                    <FP SOURCE="FP-1">• § 170.207(s)—Patient insurance</FP>
                    <P>We propose that adoption of the standard in § 170.207(s)(1), Public Health Data Standards Consortium Source of Payment Typology Code Set Version 5.0 (October 2011), would expire on January 1, 2026.</P>
                    <P>
                        In addition to updating the minimum standards code sets listed above, we propose to update the certification criteria that reference those minimum standards. These certification criteria include §§ 170.315(a)(12), 170.315(b)(1)(iii)(B)(
                        <E T="03">2</E>
                        ) and (G)(
                        <E T="03">3</E>
                        ), 170.315(c)(4)(iii)(C), (E), (G), (H), and (I), 170.315(f)(1)(i)(B)-(C), 170.315(f)(3)(ii) and (f)(4)(ii).
                    </P>
                    <HD SOURCE="HD3">6. New Imaging Requirements for Health IT Modules</HD>
                    <P>Diagnostic images are critical to supporting care in a variety of healthcare settings. Clinicians routinely use diagnostic images to support patient care and patients can better facilitate and coordinate care when they have access to their own images. Diagnostic images are often stored in systems external to an EHR, such as picture archiving and communication systems (PACS), vendor neutral archives (VNA), or other imaging platforms. While radiologists, ophthalmologists, dermatologists, pathologists, and other imaging specialists generally have direct access to full diagnostic quality images on these systems, access to both diagnostic quality and lesser quality images for referring providers can be inconsistent, depending on how broadly the hospitals or provider practice deploys access to their imaging infrastructure.</P>
                    <P>
                        While certain images may be exchanged electronically in an automated manner, patients are often provided their diagnostic quality images on physical media (
                        <E T="03">e.g.,</E>
                         compact disc read-only memory (CD-ROM)) to physically transport to their next clinical visit. Some PACS and VNA systems provide access to images through a web-based viewer, but those web-based viewers are often not accessible outside of the hospital or practice's immediate network.
                    </P>
                    <P>
                        In the Health Information Technology: Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology, 2014 Edition; Revisions to the Permanent Certification Program for Health Information Technology (2014 Edition Final Rule), ONC adopted an “Image Results” certification criterion to 
                        <PRTPAGE P="63521"/>
                        support the CMS EHR Incentive Program requirement, also known as the Meaningful Use or “MU Stage 2 Objective” requirement, that required eligible clinicians, eligible hospitals, and critical access hospitals to have access to imaging results and information through Certified EHR Technology (77 FR 54172).
                        <SU>35</SU>
                        <FTREF/>
                         The certification criterion required a Health IT Module to indicate the availability of a patient's images and narrative interpretations and enable access to those images and narrative interpretations. ONC stated that the requirements of this certification criterion could be met via the capability to directly link to images stored in the EHR system or providing a context-sensitive link to an external application which provides access to images and their associated narrative. We also stated in the 2014 Edition Final Rule that the use of the Digital Imaging and Communications in Medicine (DICOM) standard (or any other imaging standards) was unnecessary to meet the functional requirement expressed in the imaging results certification criterion (77 FR 54173). Instead, we reiterated our understanding stated in the 2014 Edition Proposed Rule that the adoption of standards was unnecessary to enable users to electronically access images and their narrative interpretations, as required by this certification criterion (77 FR 13838).
                    </P>
                    <FTNT>
                        <P>
                            <SU>35</SU>
                             For more discussion regarding ONC's support of the CMS EHR Incentive Program, Stage 2 Meaningful Use, please 
                            <E T="03">see: https://www.cms.gov/newsroom/fact-sheets/cms-proposes-definition-stage-2-meaningful-use-certified-electronic-health-records-ehr-technology.</E>
                        </P>
                    </FTNT>
                    <P>In the 2015 Edition Proposed Rule, ONC proposed to maintain the “Imaging Results” certification criterion (80 FR 16822) and while some commenters supported this proposal, ONC ultimately removed the “Imaging Results” certification criterion in the 2015 Edition Final Rule because the associated CMS EHR Incentive Programs objective (now referred to as Promoting Interoperability objectives) was removed and no longer required technological support (80 FR 62683). Instead, we finalized a certification criterion related to imaging in § 170.315(a)(3) “Computerized provider order entry—diagnostic imaging,” which is currently available for certification in the Program and requires that a Health IT Module enable a user to record, change, and access diagnostic imaging orders.</P>
                    <P>
                        We acknowledge there are certain use cases and circumstances where image access via physical media may be more appropriate than network access (
                        <E T="03">e.g.,</E>
                         locations without adequate network capabilities). However, we believe the prevalence of CD-ROMs and other physical media to share diagnostic quality images across healthcare settings indicates a lack of interoperability and access to imaging results that represents a continued burden for patients and clinicians. The widespread use of CD-ROMs and other physical media to share diagnostic quality images persists despite the adoption of PACS and VNA systems, the implementation of web-based viewers for diagnostic imaging, and the emergence of electronic standards and profiles meant to facilitate medical image access and exchange. For instance, the DICOM standard establishes a service-based process for web-based medical imaging, DICOMweb
                        <E T="51">TM</E>
                        . The Integrating the Healthcare Enterprise (IHE) XCPD, XCA, and XCA-I profiles support electronic transactions that can be used to facilitate medical imaging access. While these standards and others currently exist, there is not yet a clear consensus or full adoption of these pathways in health IT.
                    </P>
                    <P>
                        ONC believes that promoting access to and the exchange of images via Program requirements may encourage more widespread adoption and integration of these already existing pathways and reduce burdens caused by physical media exchange. Therefore, we propose to revise three certification criteria by adding new provisions to include support of a link to diagnostic imaging: “transitions of care” in § 170.315(b)(1); “application access—all data request” in § 170.315(g)(9); and “standardized API for patient and population services” in § 170.315(g)(10). We describe in subsequent paragraphs the criterion-specific details of the proposals to require support for imaging links in the Program. We believe that support for imaging links in these certification criteria will promote the availability of electronic image access for patients and providers. To enable a consistent understanding of “imaging link” across certification criteria requirements in the Program, we propose to define “imaging link” in § 170.102 to be “technical details which enable the electronic viewing or retrieval of one or more images over a network.” The proposed definition of “imaging link” is intended to be sufficiently broad to include the technical details used by the protocols and technologies implemented by industry to view and retrieve images. We also note that there is no specific standard associated with the support of this link, and that the functionality of this requirement can be met with a context-sensitive link to an external application which provides access to images and their associated narrative. The DICOMweb standard (
                        <E T="03">e.g.,</E>
                         DICOM PS3.18 2023d—Web Services) 
                        <SU>36</SU>
                        <FTREF/>
                         is likely to be among the standards widely used by hospitals and providers to support imaging links, but the Health IT Module certified to these certification criteria is not required to support a specific standard. We also clarify that although this proposal does not include specific security standards, we expect the appropriate authentication and authorization processes to be supported to prevent unauthorized access via the imaging links required in this proposal. For example, health IT developers may consider SMART Health Links as one possible standard by which to generate secure links to patient images.
                    </P>
                    <FTNT>
                        <P>
                            <SU>36</SU>
                             
                            <E T="03">https://dicom.nema.org/medical/dicom/2023d/.</E>
                        </P>
                    </FTNT>
                    <P>We propose to revise the § 170.315(b)(1) “Transitions of care” certification criterion to support imaging links by adding imaging links to the data required to be supported in the “Create” functionality in § 170.315(b)(1)(iii) by adding a new paragraph in § 170.315(b)(1)(iii)(H). The “Create” functionality in § 170.315(b)(1)(iii) specifies the requirement to enable a user to create a transition of care/referral summary formatted in accordance with the standard specified in § 170.205(a)(3), (4), and (5) using the Continuity of Care Document, Referral Note, and (inpatient setting only) Discharge Summary document templates including at a minimum the data described under § 170.315(b)(1)(iii)(A)—(G). We propose specifically to add a paragraph in § 170.315(b)(1)(iii)(H) to indicate on and after January 1, 2028 imaging links are a part of the minimum “Create” requirements in § 170.315(b)(1)(iii).</P>
                    <P>
                        We propose to revise the § 170.315(g)(9) “Application access—all data request” certification criterion to support imaging links by adding imaging links to the data required to be supported in responses to requests for patient data in a summary record formatted according to the data response requirements at paragraphs in § 170.315(g)(9)(i)(A)(
                        <E T="03">1</E>
                        ) and (
                        <E T="03">2</E>
                        ). Specifically, we propose to add a paragraph § 170.315(g)(9)(i)(A)(
                        <E T="03">3</E>
                        )(
                        <E T="03">v</E>
                        ) that indicates on and after January 1, 2028 imaging links are required to be supported as part of the data response requirements in § 170.315(g)(9)(i)(A)(
                        <E T="03">1</E>
                        ) and (
                        <E T="03">2</E>
                        ). We also propose to revise the data response requirements in paragraphs § 170.315(g)(9)(i)(A)(
                        <E T="03">1</E>
                        ) and (
                        <E T="03">2</E>
                        ) to reference the data requirements proposed in § 170.315(g)(9)(i)(A)(
                        <E T="03">3</E>
                        )(
                        <E T="03">v</E>
                        ).
                        <PRTPAGE P="63522"/>
                    </P>
                    <P>
                        We propose to revise the § 170.315(g)(10) “Standardized API for patient and population services” certification criterion to support imaging links by adding imaging links to the data required to be supported for data response for patients and users and for data response for systems. Specifically, we propose to add imaging links as data required to be supported on and after January 1, 2028 in data response for patients and users consistent with FHIR and US Core requirements at the paragraph proposed in § 170.315(g)(10)(ii)(B)(
                        <E T="03">1</E>
                        ). Additionally, we propose to add imaging links as data required to be supported on and after January 1, 2028 in data response for systems consistent with FHIR and US Core requirements proposed in § 170.315(g)(10)(iii)(B)(
                        <E T="03">1</E>
                        ), and the Bulk FHIR API data response for systems in accordance with FHIR, US Core, and Bulk Data Access, including the “_type” query parameter, requirements proposed in § 170.315(g)(10)(iii)(B)(
                        <E T="03">2</E>
                        ) and § 170.315(g)(10)(iii)(B)(
                        <E T="03">2</E>
                        )(
                        <E T="03">ii</E>
                        ).
                    </P>
                    <P>
                        We also propose to revise the “view, download, and transmit to 3rd party” certification criterion in § 170.315(e)(1) to add functional support for viewing and download of diagnostic quality and lower quality images as well as inclusion of an imaging link to those diagnostic images in either a downloaded or transmitted Continuity of Care Document (CCD). We propose that Health IT Modules support this functionality on and after January 1, 2028. Specifically, we propose to add both diagnostic quality images and reduced quality images to the data that must be supported for viewing by patients (and their authorized representatives) according to paragraph (e)(1)(i)(A) by including support for diagnostic quality images and reduced quality images at the proposed paragraph (e)(1)(i)(A)(
                        <E T="03">8</E>
                        ). Furthermore, we propose to include imaging links in the requirements in § 170.315(e)(1)(i)(B)(
                        <E T="03">2</E>
                        )(
                        <E T="03">i</E>
                        ) and (
                        <E T="03">ii</E>
                        ) specifying the data required to be included at a minimum in ambulatory summaries and inpatient summaries respectively be downloadable in accordance with the requirements specified at paragraph (e)(1)(i)(B)(
                        <E T="03">2</E>
                        ), which details the download requirements for ambulatory summaries and inpatient summaries downloaded according to the standard specified in § 170.205(a)(4) through (6) following the CCD document template. Finally, we propose that patients (and their authorized representatives) must be able to use technology to download both diagnostic quality and reduced quality images at the proposed § 170.315(e)(1)(i)(B)(
                        <E T="03">4</E>
                        ). Like broad requirements proposed in § 170.315(e)(1)(i)(A)(
                        <E T="03">8</E>
                        ), we propose that Health IT Modules certified to § 170.315(e)(1) support these specific scenarios on and after January 1, 2028. Again, there is no standard specified for either the images or the imaging links in the proposed requirements, though we anticipate that DICOM and the DICOMweb standard (such a—DICOM PS3.18 2023d—Web Services) are likely to be among standards widely used by hospitals and providers to support images and imaging links respectively.
                    </P>
                    <P>We believe it is important to support the ability to view and download both diagnostic and lower quality images. While it is critical for patients to have access to diagnostic imaging, lower quality images are also important and, for example, a patient may decide that it is useful to have the lower quality images for quick reference. This revised certification criterion requires that both types of imaging be supported for viewing and for direct downloading by patients.</P>
                    <P>The view and download requirements of this certification criterion could be met via the capability to directly link to images stored in the Health IT Module or providing a context-sensitive connection to an external application which provides access to images and their associated narrative. In either case, however, the view and download functionalities must be accessible to the patient through the same internet-based technology as the other functionalities of § 170.315(e)(1). Electronic exchange of the image itself does not need to be included as part of the § 170.315(e)(1)(C) “Transmit to third party” functionality. However, similar to the proposals for the other certification criteria discussed above, an imaging link to the images accessible to the patient must be provided.</P>
                    <P>We propose that on and after January 1, 2028, a Health IT Module seeking certification to any of the certification criteria in § 170.315(b)(1), (e)(1), (g)(9), and (10), must meet the proposed requirements for imaging links. We note that health IT developers are also required to meet the Assurances Condition of Certification maintenance requirement in § 170.402(b)(3) that any health IT developer with a Health IT Module certified to these certification criteria would need to update their Health IT Modules and provide the updated version to their customers, including the most recently adopted capabilities and standards included in the revised certification criteria order to maintain certification of that Health IT Module. We welcome comments on these proposals.</P>
                    <HD SOURCE="HD3">7. Revised Clinical Information Reconciliation and Incorporation Criterion</HD>
                    <P>We propose to revise the “Clinical information reconciliation and incorporation” (CIRI) certification criterion in § 170.315(b)(2). These proposed revisions are intended to expand our existing CIRI certification requirements to additional data elements and promote new capabilities that would benefit providers by reducing the burden of reconciliation and incorporation in clinical workflows.</P>
                    <P>Our requirements for CIRI in the Program were first established in the “Health Information Technology: Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology” Jan. 13, 2010, interim final rule to enable a user to electronically compare two or more medication lists (75 FR 2014). We subsequently expanded these requirements in the 2014 Edition Final Rule to require clinical information reconciliation and incorporation for three data types: problems, medications, and medication allergies (77 FR 54222). We noted in the 2010 interim final rule that there was, “. . . great promise in making this [reconciliation] capability more comprehensive” and that we “anticipate exploring ways to improve the [reconciliation] utility of this capability. . .” (75 FR 44613). In the 2014 Edition Final Rule we also noted our agreement with public comments that said providers “should have some control over how exactly they want to be able to incorporate data into their EHR technology as part of their practice/organization” (77 FR 54219).</P>
                    <P>
                        Building on our CIRI strategy and in response to public feedback, we propose to revise § 170.315(b)(2) to require Health IT Modules to support reconciliation and incorporation of all USCDI data elements. In the context of the CIRI workflow in § 170.315(b)(2), we propose that upon receipt of a transition of care/referral summary all USCDI data elements must be supported, at a minimum, for reconciliation and incorporation by a user in § 170.315(b)(2)(v). We also propose in § 170.315(b)(2)(vi) user configuration functionality to enable a user to set individual or organizational rules that allow automatic reconciliation and incorporation for each data class included in at least one of the versions of the USCDI standard in § 170.213, including functionality that allows the 
                        <PRTPAGE P="63523"/>
                        user to select trusted data and trusted data sources for automatic reconciliation and incorporation. Finally, as part of our proposed revision to the CIRI certification criterion in § 170.315(b)(2), we propose system verification functionality in § 170.315(b)(2)(vii) that requires Health IT Modules to be able to create a file formatted according to the Continuity of Care Document template.
                    </P>
                    <P>We propose to implement this by requiring Health IT Modules certified to § 170.315(b)(2) to meet the requirements in§ 170.315(b)(2)(i), (ii), (iii), and (vii), or the requirements in (iv), (v), (vi) and (vii) for the time period up to and including December 31, 2027. On and after January 1, 2028, we propose that Health IT Modules certified to § 170.315(b)(2) must meet the requirements in § 170.315(b)(2)(iv), (v), (vi), and (vii).</P>
                    <P>Our proposed revised CIRI requirements in § 170.315(b)(2)(iv), (v), and (vi) include reorganizing and generalizing the CIRI workflow requirements currently in the certification criterion in § 170.315(b)(2)(i), (ii), and (iii). Specifically, we have generalized and combined requirements currently in § 170.315(b)(2)(i) and (ii) in proposed § 170.315(b)(iv) and we have replicated requirements currently in § 170.315(b)(2)(iii) in proposed § 170.315(b)(v) under “user reconciliation,” with the aforementioned proposal to reference all data classes and data elements in the USCDI standard in § 170.213 instead of the currently referenced “medications,” “allergies and intolerance,” and “problems” data elements. Additionally, we propose to move our system verification requirements currently finalized in § 170.315(b)(2)(iv) into § 170.315(b)(2)(vii) and we propose, for clarity, to break these system verification requirements up into sub-paragraphs under § 170.315(b)(2)(vii).</P>
                    <P>
                        Given the goal of USCDI to support “data elements for nationwide, interoperable health information exchange,” 
                        <SU>37</SU>
                        <FTREF/>
                         we believe this proposal supports interoperability and continues to advance our policy objectives for widespread electronic health information exchange. Additionally, we believe that these requirements would help equip providers with additional, relevant, and sometimes critical clinical information that can improve overall patient care. We envision that the ability to reconcile and incorporate both structured and unstructured data elements of the USCDI would be a welcomed functionality to improve patient care, note bloat,
                        <SU>38</SU>
                        <FTREF/>
                         and clinician burden.
                    </P>
                    <FTNT>
                        <P>
                            <SU>37</SU>
                             
                            <E T="03">https://www.healthit.gov/isa/united-states-core-data-interoperability-uscdi.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>38</SU>
                             Rule A, Bedrick S, Chiang MF, Hribar MR. Length and Redundancy of Outpatient Progress Notes Across a Decade at an Academic Medical Center. 
                            <E T="03">JAMA Netw Open.</E>
                             2021;4(7): e2115334. doi:10.1001/jamanetworkopen.2021.15334.
                        </P>
                    </FTNT>
                    <P>We note that there can be multiple approaches for supporting user reconciliation and we have stated previously, “in the event that data is in unstructured form, any method implemented by which the EHR is capable of assisting in reconciliation is acceptable” (77 FR 54224). We believe that developers have technology readily available for assisting users in reconciling and incorporating data and we maintain that this approach would continue support for innovation.</P>
                    <HD SOURCE="HD3">Alternative Proposal to Revised CIRI Criterion in § 170.315(b)(2)</HD>
                    <P>As an alternative proposal, narrower in scope and on which we seek public comment, we are also considering whether to limit the expansion of our incorporation and reconciliation requirements, that must be met on and after January 1, 2028, to just nine specific USCDI data classes (six new data classes plus the existing three Allergies and intolerance, Medications, and Problems data classes).</P>
                    <P>The limited data classes in USCDI v4 we have identified for this alternative proposal are: Allergies and Intolerances, Care Team Members, Goals and Preferences, Immunizations, Laboratory, Medications, Medical Devices, Patient Summary and Plan, and Problems. Across these nine data classes, the USCDI v4 includes the following:</P>
                    <P>• The data elements in the Allergies and Intolerances data class include Substance (Medication), Substance (Drug Class), Substance (Non-Medication) and Reaction.</P>
                    <P>• The data elements in the Care Team Member(s) data class include Care Team Member Name, Care Team Member Identifier, Care Team Member Role, Care Team Member Location, and Care Team Member Telecom.</P>
                    <P>• The data elements in the Goals and Preferences data class include Patient Goals, SDOH Goals, Treatment Intervention Preference, and Care Experience Preference.</P>
                    <P>• The one data element in the Immunizations data class is Immunizations.</P>
                    <P>• The data elements in the Laboratory data class include Tests, Values/Results, Specimen Type, Result Status, Result Unit of Measure, Result Reference Range, Result Interpretation, Specimen Source Site, Specimen Identifier, and Specimen Condition Acceptability.</P>
                    <P>• The data elements in Medications include Medications, Dose, Dose Unit of Measure, Indication, Fill Status, Medications Instructions, and Medication Adherence.</P>
                    <P>• The data element in the Medical Devices data class is Unique Device Identifier—Implantable.</P>
                    <P>• The data element in the Patient Summary and Plan data class is Assessment and Plan of Treatment.</P>
                    <P>• The data elements in Problems include Problems, SDOH Problems/Health Concerns, Date of Diagnosis, and Date of Resolution.</P>
                    <P>We selected these data classes based on feedback from industry and existing industry support as well as our understanding of importance for improved patient care. We believe that the standards referenced for these data elements are mature enough or the information they relay are important enough to patient care to warrant inclusion as part of the CIRI workflow as part of this alternative proposal for a more moderate expansion. </P>
                    <P>We welcome comment on expanding our CIRI certification requirements to only a limited set of a USCDI data classes versus referencing all USCDI. Additionally, if a limited set of different data elements within the USCDI is preferred, we welcome comments on what subset of USCDI data classes and elements should be referenced in the certification criterion as most necessary for reconciliation and better patient care.</P>
                    <HD SOURCE="HD3">Automatic Reconciliation and Incorporation Capabilities in Revised CIRI Criterion in § 170.315(b)(2)</HD>
                    <P>
                        In addition to our proposed updated CIRI requirements that support all USCDI, we also propose in § 170.315(b)(2)(vi) new functional requirements to enable user-driven automatic reconciliation and incorporation for Health IT Modules certified to § 170.315(b)(2). We believe that users and health care providers are best situated to determine which clinical data and data sources require manual review and which are better suited to automatic reconciliation and incorporation. To ensure that Health IT Modules certified to § 170.315(b)(2) have the capability to support user-driven automatic reconciliation and incorporation, we propose in § 170.315(b)(2)(vi), that Health IT Modules certified to § 170.315(b)(2) would need to provide functionality that would allow automatic reconciliation and incorporation, without manual review, for each of the 
                        <PRTPAGE P="63524"/>
                        applicable USCDI data elements. We note that nothing in this proposal would compel automatic reconciliation and incorporation for specific workflows or use cases. Rather, our intention is to empower users in determining the circumstances under which clinical data can be automatically reconciled and incorporated, we also propose new configuration requirements in § 170.315(b)(2)(vi) to enable users to set rules indicating specific data and/or specific data sources for automatic reconciliation and incorporation.
                    </P>
                    <P>We note that automatic incorporation means any process by which USCDI data elements contained within C-CDAs are automatically reconciled with information within certified health IT and incorporated in the 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. We welcome comment on this proposal.</P>
                    <P>We believe that these revisions would provide users with the ability to configure their workflows in such a way as to maximize patient care while minimizing provider effort to perform reconciliation and incorporation. As we have stated in a previous rule when expanding CIRI requirements, “we believe that EHR technology can be designed to assist users in remarkable ways and that reconciling information from multiple sources in a way that is assistive to a user is something at which EHR technology should excel” (77 FR 13849). We believe this proposal is aligned with similar functionalities that many developers are already developing. Our goal is to advance baseline functionality while also leaving room for innovation. We propose that Health IT Modules must support the proposed automatic reconciliation and incorporation capabilities on and after January 1, 2028. We welcome comment on this proposed functionality.</P>
                    <HD SOURCE="HD3">8. Revised Electronic Prescribing Certification Criterion</HD>
                    <P>
                        We propose to update the “electronic prescribing” certification criterion in § 170.315(b)(3). The proposed updates include updating the core standard for electronic prescribing to NCPDP SCRIPT standard version 2023011,
                        <SU>39</SU>
                        <FTREF/>
                         which is cross-referenced in § 170.205(b)(2) in the proposed text in § 170.315(b)(3)(ii)(A). We also propose revisions to the transactions within the SCRIPT standard that would be required for the updated certification criterion and propose to remove a number of transactions that are currently identified as optional for the criterion. Finally, we propose to remove § 170.315(b)(3)(i) from the CFR upon the effective date of this rule and reserve it as this version of the certification criterion is no longer valid for use in the Program.
                    </P>
                    <FTNT>
                        <P>
                            <SU>39</SU>
                             
                            <E T="03">See https://standards.ncpdp.org/Access-to-Standards.aspx.</E>
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">a. Electronic Prescribing Standard</HD>
                    <P>
                        In the “Medicare Program; Medicare Prescription Drug Benefit Program; Health Information Technology Standards and Implementation Specifications” final rule (Part D and Health IT Standards Final Rule), which appeared in the 
                        <E T="04">Federal Register</E>
                         on June 17, 2024 (89 FR 51238 through 51265), we adopted NCPDP SCRIPT standard version 2023011 in § 170.205(b)(2). We also finalized an expiration date for NCPDP SCRIPT standard version 2017071 of January 1, 2028, in § 170.205(b)(1), which reflected a delay of one year from the expiration date we had proposed (88 FR 78501). We also finalized the removal of the NCPDP SCRIPT standard version 10.6, which was located in § 170.205(b)(2) (89 FR 51258 and 51259). The finalization of these policies in the Part D and Health IT Standards Final Rule, and CMS' finalization of cross references to § 170.205(b) in their requirements for the Part D Program, reflects a unified approach to aligning standards adoption across HHS programs that impact a common set of participants (88 FR 78486 through 78494).
                    </P>
                    <P>
                        We note that we previously proposed to adopt NCPDP SCRIPT standard version 2022011 and made other proposals in the “Medicare Program; Contract Year 2024 Policy and Technical Changes to the Medicare Advantage Program, Medicare Prescription Drug Benefit Program, Medicare Cost Plan Program, Medicare Parts A, B, C, and D Overpayment Provisions of the Affordable Care Act and Programs of All-Inclusive Care for the Elderly; Health Information Technology Standards and Implementation Specifications” proposed rule (2024 Part C/D Proposed Rule), which appeared in the 
                        <E T="04">Federal Register</E>
                         on December 27, 2022 (87 FR 79555). However, we subsequently withdrew these proposals in the “Medicare Program; Contract Year 2025 Policy and Technical Changes to the Medicare Advantage Program, Medicare Prescription Drug Benefit Program, Medicare Cost Plan Program, and Programs of All-Inclusive Care for the Elderly; Health Information Technology Standards and Implementation Specifications” proposed rule (2025 Part C/D Proposed Rule), which appeared in the 
                        <E T="04">Federal Register</E>
                         on November 15, 2023 (88 FR 78476), and instead proposed to adopt the NCPDP SCRIPT standard version 2023011 in § 170.205(b)(2) (88 FR 78501 through 78502).
                    </P>
                    <P>In this proposed rule, we propose in § 170.315(b)(3)(ii)(A) that for the time period up to and including December 31, 2027, a Health IT Module certified to the “electronic prescribing” certification criterion at 45 CFR 170.315(b)(3) must enable a user to perform the following prescription-related electronic transactions in accordance with the standard specified in § 170.205(b)(1) (NCPDP SCRIPT standard version 2017071) or § 170.205(b)(2) (NCPDP SCRIPT standard version 2023011). We also propose that on and after January 1, 2028, a Health IT Module certified to the “electronic prescribing” certification criterion must enable a user to perform the following prescription-related electronic transactions in accordance with only the standard specified in § 170.205(b)(2) (NCPDP SCRIPT standard version 2023011). This means that a health IT developer may continue to maintain health IT certification conformance to NCPDP SCRIPT standard version 2017071 (in § 170.205(b)(1)) for the time period up to and including December 31, 2027. On and after January 1, 2028, consistent with our policy in § 170.402(b), developers of certified health IT with Health IT Modules certified to the “electronic prescribing” certification criterion will need update those Health IT Modules to the standard in § 170.205(b)(2) and provide them to customers. This is consistent with the date of January 1, 2028, that we finalized for the expiration of NCPDP SCRIPT standard version 2017071 in § 170.205(b)(1) in the Part D and Health IT Standards Final Rule (89 FR 51259). We also propose in § 170.315(b)(3)(ii)(A) that the Health IT Module must use RxNorm (which we have adopted in § 170.207(d)(1)), and, if using NCPDP SCRIPT standard version 2023011, National Drug Codes (which we cross reference in § 170.207(d)(2)).</P>
                    <HD SOURCE="HD3">b. Proposed Transactions</HD>
                    <P>
                        We propose the following updates and changes to the transactions identified for the “electronic prescribing” certification criterion in § 170.315(b)(3)(ii).
                        <PRTPAGE P="63525"/>
                    </P>
                    <HD SOURCE="HD3">New Prescriptions (NewRx) (§ 170.315(b)(3)(ii)(A)(1))</HD>
                    <P>
                        We propose in § 170.315(b)(3)(ii)(A)(
                        <E T="03">1</E>
                        ) to revise the name used for the NewRx transaction in our regulations from “Create New Prescriptions (NewRx)” to “New Prescriptions (NewRx).” We propose this change to align with updated terminology used by NCPDP within the SCRIPT standard.
                    </P>
                    <HD SOURCE="HD3">Request and Receive Medication History (§ 170.315(b)(3)(ii)(A)(6))</HD>
                    <P>
                        We propose to remove the request and receive medication history transactions (RxHistoryRequest, RxHistoryResponse) as a requirement for the “electronic prescribing” certification criterion in § 170.315(b)(3)(ii)(A)
                        <E T="03">(6)</E>
                         and reserve this section.
                    </P>
                    <P>
                        In the ONC Cures Act Final Rule, ONC finalized the request and receive medication history transactions (RxHistoryRequest, RxHistoryResponse) in the “electronic prescribing” certification criterion (85 FR 25682). Since the final rule was published, health IT developers and health care providers have described several challenges meeting this requirement, including development burden; lower than expected adoption and use; and duplicative, overlapping, and sometimes contradictory data from multiple sources. Due in part to these challenges and market forces that have prevented some developers from adopting this functionality natively, developers have had to rely on third-party applications to achieve certification, and in some cases, are unable to achieve certification for electronic prescribing altogether. As such, we propose these transactions would no longer be required for certification to the “electronic prescribing” criterion in § 170.315(b)(3)(ii)(A)
                        <E T="03">(6).</E>
                         We also propose to reserve section § 170.315(b)(3)(ii)(A)
                        <E T="03">(6).</E>
                    </P>
                    <P>We continue to encourage developers to support these transactions where possible and to follow industry efforts to advance the exchange of patient medication histories through various means such as health information exchanges, health information networks, and prescription drug monitoring programs. We further note that, while health IT developers would not be required to demonstrate compliance with these transactions in order for a Health IT Module to be certified to the updated version of the “electronic prescribing” criterion (if our proposals are finalized), CMS still requires use of these transactions when appropriate for electronic exchange of prescription-related information by Part D sponsors and prescribers and dispensers of Part D drugs for Part D eligible individuals (88 FR 78486). Health IT developers would still need to support these transactions when supporting customers who utilize these transactions to exchange electronic Part D medication history information among Part D sponsors and prescribers and dispensers of Part D drugs for Part D eligible individuals in compliance with requirements, currently codified at 42 CFR 423.160(b)(4) and finalized to be codified at 42 CFR 423.160(b)(1)(i)(U) in the Part D and Health IT Standards Final Rule (89 FR 51247).</P>
                    <P>We request comments on this proposal.</P>
                    <HD SOURCE="HD3">Electronic Prior Authorization Transactions (§ 170.315(b)(3)(ii)(A)(10))</HD>
                    <P>We propose to require the following transactions for electronic prior authorization for the “electronic prescribing” certification criterion, at the time a health IT developer presents a Health IT Module for certification using the standard in § 170.205(b)(2) (NCPDP SCRIPT standard version 2023011): PAInitiationRequest, PAInitiationResponse, PARequest, PAResponse, PAAppealRequest, PAAppealResponse, PACancelRequest, and PACancelResponse.</P>
                    <P>
                        In the ONC Cures Act Final Rule, ONC adopted these transactions in § 170.315(b)(3)(ii)(B)(
                        <E T="03">9</E>
                        ) as optional for the “electronic prescribing” certification criterion (85 FR 25678). We stated that we adopted these transactions to support alignment with the “Medicare Program; Secure Electronic Prior Authorization for Medicare Part D” proposed rule (84 FR 28450), in which CMS proposed to require Part D sponsors to support NCPDP SCRIPT standard version 2017071 for four electronic prior authorization transactions, and proposed that prescribers would be required to use that standard when performing electronic prior authorization transactions for Part D covered drugs they wish to prescribe to Part D eligible individuals (85 FR 25685). CMS subsequently finalized in the “Medicare Program; Secure Electronic Prior Authorization for Medicare Part D” final rule in § 423.160(b)(8)(ii) that beginning January 1, 2022, Part D sponsors and prescribers must use the NCPDP SCRIPT standard version 201701 (85 FR 86832). The ONC Cures Act Final Rule allowed health IT developers seeking certification to support these transactions through optional testing but did not require developers to certify to these transactions.
                    </P>
                    <P>
                        We have received feedback from the public in support of requiring these transactions, most recently in response to the “Request for Information: Electronic Prior Authorization Standards, Implementation Specifications, and Certification Criteria” (Electronic Prior Authorization RFI), which was published in the 
                        <E T="04">Federal Register</E>
                         on January 24, 2022 (87 FR 3475). Commenters stated that requiring these transactions for the certification criterion would help to advance interoperability and reduce administrative burden around prior authorization processes for medications. We agree with this input and believe that it is appropriate to require these transactions at this time. Therefore, we propose to remove PAInitiationRequest, PAInitiationResponse, PARequest, PAResponse, PAAppealRequest, PAAppealResponse, PACancelRequest, and PACancelResponse in § 170.315(b)(3)(ii)(B)(
                        <E T="03">9</E>
                        ) as optional and propose to require these transactions in § 170.315(b)(3)(ii)(A)(
                        <E T="03">10</E>
                        ) for the “electronic prescribing” certification criterion at the time a health IT developer presents a Health IT Module for certification using NCPDP SCRIPT standard version 2023011.
                    </P>
                    <P>
                        ONC also charged the HITAC to establish a Task Force in order to provide input and recommendations in response to the Electronic Prior Authorization RFI; the Task Force's recommendations were approved and submitted to ONC on March 10, 2022.
                        <SU>40</SU>
                        <FTREF/>
                         If finalized, the proposals in this rule would implement the Task Force's recommendation to update these prior authorization transactions from “optional” in the current version of the “electronic prescribing” certification criterion to “mandatory,” to better support electronic prior authorization processes for drugs covered under a prescription benefit.
                    </P>
                    <FTNT>
                        <P>
                            <SU>40</SU>
                             
                            <E T="03">https://www.healthit.gov/sites/default/files/page/2022-03/2022-03-10_ePA_RFI_Recommendations_Report_Signed_508.pdf.</E>
                        </P>
                    </FTNT>
                    <P>
                        We also propose to adopt the PANotification transaction in § 170.315(b)(3)(ii)(A)(
                        <E T="03">10</E>
                        ) as a required transaction for the “electronic prescribing” certification criterion to further support the exchange of electronic prior authorization information. PANotification is a new transaction introduced since NCPDP SCRIPT standard version 2017071. The PANotification transaction is used to alert the pharmacist or prescriber when a prior authorization has been requested or when a prior authorization 
                        <PRTPAGE P="63526"/>
                        determination has been received. The PANotification transaction is intended to improve electronic communication between prescribers and pharmacists, and to reduce duplicate submissions of prior authorization requests to payers. Notification may occur via a NewRx, RxChange or RxRenewal transaction, or as a standalone PANotification. We believe that requiring the PANotification transaction is an important complement to the other proposals related to electronic prior authorization described above.
                    </P>
                    <P>We request comments on these proposals.</P>
                    <HD SOURCE="HD3">Optional Transactions (NewRxRequest, NewRxResponseDenied, RxFillIndicatorChange, GetMessage, Resupply, DrugAdministration, RxTransferRequest, RxTransferResponse, RxTransferConfirm, Recertification, REMSInitiationRequest, REMSInitiationResponse, REMSRequest, and REMSResponse) (§ 170.315(b)(3)(ii)(B)(1)-(8))</HD>
                    <P>
                        We propose to remove the transactions in § 170.315(b)(3)(ii)(B)(
                        <E T="03">1</E>
                        )-(
                        <E T="03">8</E>
                        ) which are currently identified as “optional” for the “electronic prescribing” certification criterion. We propose to revise § 170.315(b)(3)(ii)(B) to include requirements related to the exchange of race and ethnicity information in § 170.315(b)(3)(ii)(B)(1)-(4), which is discussed in greater detail below.
                    </P>
                    <P>Specifically, we propose to remove the following transactions in § 170.315(b)(3)(ii)(B) upon the effective date of the final rule:</P>
                    <FP SOURCE="FP-1">
                        • NewRxRequest, NewRxResponseDenied (§ 170.315(b)(3)(ii)(B)(
                        <E T="03">1</E>
                        ))
                    </FP>
                    <FP SOURCE="FP-1">
                        • RxFillIndicatorChange (§ 170.315(b)(3)(ii)(B)(
                        <E T="03">2</E>
                        ))
                    </FP>
                    <FP SOURCE="FP-1">
                        • GetMessage (§ 170.315(b)(3)(ii)(B)(
                        <E T="03">3</E>
                        ))
                    </FP>
                    <FP SOURCE="FP-1">
                        • Resupply (§ 170.315(b)(3)(ii)(B)(
                        <E T="03">4</E>
                        ))
                    </FP>
                    <FP SOURCE="FP-1">
                        • DrugAdministration (§ 170.315(b)(3)(ii)(B)(
                        <E T="03">5</E>
                        ))
                    </FP>
                    <FP SOURCE="FP-1">
                        • RxTransferRequest, RxTransferResponse, RxTransferConfirm (§ 170.315(b)(3)(ii)(B)(
                        <E T="03">6</E>
                        ))
                    </FP>
                    <FP SOURCE="FP-1">
                        • Recertification (§ 170.315(b)(3)(ii)(B)(
                        <E T="03">7</E>
                        ))
                    </FP>
                    <FP SOURCE="FP-1">
                        • REMSInitiationRequest, REMSInitiationResponse, REMSRequest, and REMSResponse (§ 170.315(b)(3)(ii)(B)(
                        <E T="03">8</E>
                        ))
                    </FP>
                    <P>
                        For completeness, we note that § 170.315(b)(3)(ii)(B) currently has transactions listed in § 170.315(b)(3)(ii)(B)(
                        <E T="03">9)</E>
                         related to electronic prior authorization. However, we proposed in the section above to remove § 170.315(b)(3)(ii)(B)(
                        <E T="03">9)</E>
                         and add the electronic prior authorization transactions currently in § 170.315(b)(3)(ii)(B)(
                        <E T="03">9)</E>
                         as required transactions in § 170.315(b)(3)(ii)(A)(
                        <E T="03">10</E>
                        ).
                    </P>
                    <P>
                        In reviewing data from the Program, we have found that very few developers have elected to certify to the optional transactions in § 170.315(b)(3)(ii)(B)(
                        <E T="03">1</E>
                        )-(
                        <E T="03">9</E>
                        ). We believe that the low rate of certification to these certification criteria indicates that health IT developers do not see a benefit in obtaining optional certification to these criteria. Accordingly, we believe that removing these optional transactions from the program will reduce the complexity and cost of the Program with minimal impact on health IT developers.
                    </P>
                    <P>We further note that CMS requires use of these transactions when appropriate for electronic exchange of prescriptions and prescription-related information by Part D sponsors and prescribers and dispensers of Part D drugs for Part D eligible individuals. Accordingly, regardless of whether a health IT developer seeks to certify its Health IT Module(s) to these optional transactions, developers will still need to support them when supporting customers who utilize these transactions to exchange information electronically between prescribers and dispensers of Part D drugs for Part D eligible individuals in compliance with requirements currently codified at 42 CFR 423.160(b)(2)(iv) and finalized to be codified at 42 CFR 423.160(b)(1)(i) in the Part D and Health IT Standards Final Rule (89 FR 51245 through 51247).</P>
                    <P>
                        We request comment on our proposal to remove the optional transactions in § 170.315(b)(3)(ii)(B)(
                        <E T="03">1</E>
                        )-(
                        <E T="03">8</E>
                        ) from the “electronic prescribing” certification criterion. Alternatively, we considered proposing to require the optional transactions in § 170.315(b)(3)(ii)(B)(
                        <E T="03">1</E>
                        )-(
                        <E T="03">8</E>
                        ) rather than removing them from the criterion. However, we did not identify additional reasons to propose to require any of these optional transactions. We request comment on this alternative, including whether commenters believe requiring any of the optional transactions in § 170.315(b)(3)(ii)(B)(
                        <E T="03">1</E>
                        )-(
                        <E T="03">8</E>
                        ) proposed for removal from the “electronic prescribing” certification criterion would be important to supporting interoperability between certified Health IT Modules and entities subject to Part D electronic prescribing requirements at 42 CFR 423.160.
                    </P>
                    <P>We refer readers to Table 1A for a comparison of transactions identified in the existing NCPDP SCRIPT standard version 2017071 and the proposed certification criterion based on NCPDP SCRIPT standard version 2023011.</P>
                    <HD SOURCE="HD3">c. Additional Proposals</HD>
                    <HD SOURCE="HD3">Signatura (Sig) (§ 170.315(b)(3)(ii)(D))</HD>
                    <P>In § 170.315(b)(3)(ii)(D), we propose that a Health IT Module certified to the “electronic prescribing” criterion must enable a user to enter, receive, and transmit structured and codified prescribing instructions in accordance with the standard specified in § 170.205(b)(2) (NCPDP SCRIPT standard version 2023011), at the time a health IT developer presents a Health IT Module for certification using the NCPDP SCRIPT standard version 2023011.</P>
                    <P>
                        The Signatura or Sig is the information provided with a prescription to communicate how a prescriber intends for a patient to take a medication. These directions for use are essential for accurate prescription labeling, appropriate patient counseling and education from a pharmacist, and optimal medication use. The NCPDP Structured and Codified Sig Format Implementation Guide,
                        <SU>41</SU>
                        <FTREF/>
                         which is embedded in the NCPDP SCRIPT standard, is intended to standardize the portion of an electronic prescription containing the directions for use using existing, accepted electronic transmission standards, such as NCPDP SCRIPT. A “structured and codified” Sig conveys instructions in a consistent manner by mapping these directions to a defined set of elements representing the different components of these directions (for instance, dosing schedules and administration instructions). The Structured and Codified Sig Format includes 15 segments, each containing distinct fields to capture potential elements of patient instructions. This is intended to facilitate communication between prescribers and pharmacists, to improve the efficiency of prescribing and dispensing activities, and to help reduce the opportunity for errors. The NCPDP Structured and Codified Sig Format Implementation Guide contains the technical specifications and guidance for implementation of a structured and codified Sig.
                    </P>
                    <FTNT>
                        <P>
                            <SU>41</SU>
                             
                            <E T="03">See https://standards.ncpdp.org/Access-to-Standards.aspx.</E>
                        </P>
                    </FTNT>
                    <P>
                        When conducting electronic prescribing, prescribers frequently transmit the Sig Text segment as unstructured free text, which introduces inconsistency and limits reusability of the directions contained in the Sig, with potential impacts on patient safety and 
                        <PRTPAGE P="63527"/>
                        clinical outcomes.
                        <SU>42</SU>
                        <FTREF/>
                         Moreover, when unstructured free text is used, prescribers and pharmacists may have to engage in back-and-forth communication to clarify what is intended in the Sig instructions, increasing burden. Research has shown more than half of all Sig directions sent in an ambulatory setting can be accurately represented by only 25 standardized concepts (
                        <E T="03">e.g.</E>
                         the directions “take 1 tablet by oral route every day” and “Take one (1) tablet by mouth once a day” can both be represented as the same Sig concept “Take 1 tablet by mouth once daily”), indicating significant opportunities to reduce variation by expressing these directions through the structured and codified Sig format.
                        <SU>43</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>42</SU>
                             Schiff, G., Mirica, M.M., Dhavle, A.A., Galanter, W.L., Lambert, B., &amp; Wright, A. (2018). A prescription for enhancing electronic prescribing safety. Health Affairs (Project Hope), 37(11), 1877-1883. doi:
                            <E T="03">https://doi.org/10.1377/hlthaff.2018.0725.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>43</SU>
                             Yang, Y., Ward-Charlerie, S., Dhavle, A.A., Rupp, M.T., &amp; Green, J. (2018). Quality and Variability of Patient Directions in Electronic Prescriptions in the Ambulatory Care Setting. Journal of managed care &amp; specialty pharmacy, 24(7), 691-699. 
                            <E T="03">https://doi.org/10.18553/jmcp.2018.17404.</E>
                        </P>
                    </FTNT>
                    <P>Previously, in the 2015 Edition Final Rule, we did not finalize our proposal to require a Health IT Module certified to the “electronic prescribing” criterion to enable a user to enter, receive, and transmit codified Sig instructions in a structured format, based on commenters' concerns regarding the readiness of the standard and other issues such as limitations on the length of a Sig within the version of the NCPDP SCRIPT Structured and Codified Sig Format v1.2 available at the time of the proposal (80 FR 62643). We stated that we would reconsider this stance for future rulemaking based on newer versions of the NCPDP SCRIPT Standard Implementation Guide that may provide implementation improvements and finalized an optional certification provision that technology must be able to receive and transmit the reason for the prescription using the indication elements in the SIG segment in § 170.315(b)(3)(i) (80 FR 62643). In the ONC Cures Act Final Rule, we also finalized this optional provision in § 170.315(b)(3)(ii)(D) (85 FR 25686).</P>
                    <P>
                        Since the 2015 Edition Final Rule, NCPDP has further advanced the structured and codified Sig format. The most recent version available is the NCPDP Structured and Codified Sig Implementation Guide version 2.2. The structured and codified Sig segment within the NCPDP SCRIPT standard has also been modified; changes to the Sig element from NCPDP SCRIPT standard version 2017017 are discussed in the NCPDP SCRIPT standard version 2023011 Implementation Guide.
                        <SU>44</SU>
                        <FTREF/>
                         As a result of additional improvements made to the structured and codified Sig format, as well as the additional time that industry has had to grow familiar with this functionality, we believe that it is appropriate to propose in § 170.315(b)(3)(ii)(D) to require that a Health IT Module certified to the “electronic prescribing” criterion must enable a user to enter, receive, and transmit structured and codified prescribing instructions in accordance with the standard specified in § 170.205(b)(2) (where we have adopted NCPDP SCRIPT standard version 2023011), at the time a health IT developer presents a Health IT Module for certification using NCPDP SCRIPT standard version 2023011. We propose to remove the optional provision that is currently in § 170.315(b)(3)(ii)(D).
                    </P>
                    <FTNT>
                        <P>
                            <SU>44</SU>
                             
                            <E T="03">See https://standards.ncpdp.org/Access-to-Standards.aspx.</E>
                        </P>
                    </FTNT>
                    <P>We request comments on this proposal.</P>
                    <HD SOURCE="HD3">RxNorm and National Drug Codes (NDC)</HD>
                    <P>In § 170.315(b)(3)(ii)(A) we require that a Health IT Module certified to the “electronic prescribing” criterion enable a user to perform specified prescription-related electronic transactions in accordance with a specified minimum version of the RxNorm code set for coding medications, among other standards. RxNorm, a standardized nomenclature for clinical drugs produced by the United States National Library of Medicine (RxNorm), is a drug terminology providing a set of normalized medication names and codes based on a collection of commonly used public and commercial vocabularies of drug names and their ingredients. In section III.B.5. of this proposed rule, we propose to adopt an updated release of RxNorm, specifically, the December 4, 2023, Full Monthly Release, in § 170.207(d)(1)(ii). In section III.B.5. of this proposed rule, we also propose to reorganize section § 170.207(d) to include the versions of RxNorm adopted in § 170.207(d)(1), (2), and (3), under § 170.207(d)(1).</P>
                    <P>For the “electronic prescribing” certification criterion, we propose in § 170.315(b)(3)(ii)(A) to remove the existing reference to RxNorm, September 8, 2015 Release in § 170.207(d)(3), and require use of at least one of the versions of the standard adopted in § 170.207(d)(1). If finalized, this reference to § 170.207(d)(1), where we have adopted multiple versions of RxNorm, would permit a health IT developer to use any version of RxNorm that is listed in § 170.207(d)(1) and for which adoption has not expired. This proposal would result in a requirement to use progressively more recent releases of the RxNorm code set as the baseline version of RxNorm which Health IT Modules must use for the “electronic prescribing” certification criterion.</P>
                    <P>
                        We also note that under NCPDP SCRIPT standard version 2020011 and greater, including NCPDP SCRIPT standard version 2023011, the National Drug Codes (NDC) element is required on all non-compounded medication electronic prescriptions.
                        <SU>45</SU>
                        <FTREF/>
                         National Drug Codes (NDC) provide a unique identifier for products such as vaccines or medications. Each product is assigned a unique 10- or 11-digit, 3-segment number that identifies the labeler, product, and trade package size. We adopted NDC in § 170.207(d)(4) in the HTI-1 Final Rule (89 FR 1226) via a cross-reference to 45 CFR 162.1002(b)(2) as referenced in 45 CFR 162.1002(c)(1). In section III.B.5 of this proposed rule, we propose to relocate this cross-reference from § 170.207(d)(4) to § 170.207(d)(2) as part of our reorganization of this section. Consistent with the requirement in the NCPDP SCRIPT standard version 2023011 to include NDC with prescriptions, we propose in § 170.315(b)(3)(ii)(A) that a Health IT Module certified to the criterion must enable a user to perform specified prescription-related electronic transactions in accordance with NDC in § 170.207(d)(2). We propose that use of NDC would be required at the time a health IT developer presents a Health IT Module for certification using the NCPDP SCRIPT standard version 2023011 adopted in § 170.205(b)(2).
                    </P>
                    <FTNT>
                        <P>
                            <SU>45</SU>
                             For more information about the updates to NDC in the NCPDP SCRIPT standard 
                            <E T="03">see https://ncpdp.org/NCPDP/media/images/Resources%20Items/NDC-Use-eRx-Fact-Sheet.pdf?ext=.pdf.</E>
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Diagnoses (§ 170.315(b)(3)(ii)(C))</HD>
                    <P>In § 170.315(b)(3)(ii)(C) we require that a Health IT Module “must be able to receive and transmit the reason for prescription using the diagnosis elements: &lt;DIAGNOSIS&gt; &lt;PRIMARY&gt; or &lt;SECONDARY&gt;” for the set of prescription-related transactions identified in § 170.315(b)(3)(ii)(C)(1)-(2).</P>
                    <P>
                        We propose to make changes to the list of required and optional transactions in § 170.315(b)(3)(ii)(C) to reflect the proposed required transactions for the updated version of 
                        <PRTPAGE P="63528"/>
                        the certification criterion in § 170.315(b)(3)(ii)(A), and our proposal to remove certain optional transactions from the updated version of the criterion in § 170.315(b)(3)(ii)(B). Specifically, we propose in 170.315(b)(3)(ii)(C)(
                        <E T="03">1</E>
                        ) to rename “Create New Prescriptions (NewRx)” to “New Prescriptions (NewRx).” We propose in § 170.315(b)(3)(ii)(C)(
                        <E T="03">1</E>
                        )(
                        <E T="03">vi</E>
                        ) to remove the transaction “Receive medication history” (RxHistoryResponse) and reserve this section. We propose in § 170.315(b)(3)(ii)(C)(
                        <E T="03">1</E>
                        )(
                        <E T="03">vii</E>
                        ) to require the following electronic prior authorization transactions (PAInitiationRequest, PAInitiationResponse, PARequest, PAResponse, PAAppealRequest, PAAppealResponse and PACancelRequest, PACancelResponse, PANotification) if using NCPDP SCRIPT standard version 2023011 (adopted in § 170.205(b)(2)). Lastly, we propose to remove the optional transactions in § 170.315(b)(3)(ii)(C)(
                        <E T="03">2</E>
                        )(
                        <E T="03">i</E>
                        ) through (
                        <E T="03">iv</E>
                        ) and reserve this section. We refer readers to Table 1A below in this rule for a comparison of required and optional transactions identified in the current certification criterion based on NCPDP SCRIPT standard version 2017071 and the proposed updated criterion based on NCPDP SCRIPT standard version 2023011.
                    </P>
                    <HD SOURCE="HD3">Race and Ethnicity</HD>
                    <P>
                        In 2023, the Pharmacy Interoperability and Emerging Therapeutics Task Force provided a recommendation to the HITAC to support interoperability between pharmacy constituents by including race and ethnicity in the “electronic prescribing” certification criterion (PhIET-TF-2023_Recommendation 26).
                        <SU>46</SU>
                        <FTREF/>
                         The Task Force stated that demographic data is not always made available through reporting such as case reporting to public health agencies. Yet, in order to support the ability to perform analytics, all data feeds should have relevant race and ethnicity data, and other key demographic data, when available. The Task Force recommended that various prescribing and laboratory results reporting capabilities need to be able to support sharing of the relevant data when an alternative source is not consistently available. Additionally, the Task Force acknowledged that a prescriber will likely already have patient race or ethnicity documented. Exchanging this information through available transactions, such as those included in electronic prescribing, is one way to improve consistency in documentation of demographic data across provider types.
                    </P>
                    <FTNT>
                        <P>
                            <SU>46</SU>
                             
                            <E T="03">See https://www.healthit.gov/sites/default/files/page/2023-11/2023-11-09_PhIET_TF_2023_Recommendations_Transmittal_Letter_508.pdf.</E>
                        </P>
                    </FTNT>
                    <P>
                        Specifically, the Task Force recommended ONC include the ability to capture and exchange race and ethnicity as part of the “electronic prescribing” certification criterion and point to USCDI v4,
                        <SU>47</SU>
                        <FTREF/>
                         which references the CDC Race &amp; Ethnicity Code System—CDCREC 1.2 (July 2021).
                        <SU>48</SU>
                        <FTREF/>
                         The CDC Race &amp; Ethnicity Code System—CDCREC 1.2 code set facilitates use of Federal standards for classifying data on race and ethnicity when these data are exchanged, stored, retrieved, or analyzed in electronic form. The NCPDP SCRIPT standard version 2023011, which we propose to incorporate in the “electronic prescribing” certification criterion in this proposed rule, references reporting of race and ethnicity using the CDCREC 1.2 associated value set “PHVS_Race_CDC” version 2 (December 2018 
                        <SU>49</SU>
                        <FTREF/>
                        ) from the code system code “PH_RaceAndEthnicity_CDC” as optional for certain transactions within the standard that we have also proposed to require when using the updated version of the standard. This aligns with the code system code in CDCREC 1.2 which is “PH_RaceAndEthnicity_CDC,” and is available on the Public Health Information Network (PHIN) Vocabulary Access and Distribution System (PHIN VADS).
                        <SU>50</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>47</SU>
                             
                            <E T="03">See https://www.healthit.gov/isa/united-states-core-data-interoperability-uscdi.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>48</SU>
                             
                            <E T="03">See https://www.cdc.gov/phin/resources/vocabulary/.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>49</SU>
                             
                            <E T="03">See https://phinvads.cdc.gov/vads/ViewValueSet.action?id=9152A536-AEEC-E711-ACD6-0017A477041A.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>50</SU>
                             
                            <E T="03">See https://phinvads.cdc.gov/vads/ViewCodeSystemConcept.action?oid=2.16.840.1.113883.6.238&amp;code=1579-2.</E>
                        </P>
                    </FTNT>
                    <P>Given the importance of the issues described by the Task Force, and the alignment between the recommendation and NCPDP SCRIPT standard version 2023011, we believe that it is appropriate to implement the Task Force recommendation through updates to the “electronic prescribing” certification criterion. Therefore, we propose in § 170.315(b)(3)(ii)(B) that a Health IT Module certified to the “electronic prescribing” certification criterion must enable a user to exchange race and ethnicity information for a patient when performing the following prescription-related electronic transactions, if using NCPDP SCRIPT standard version 2023011:</P>
                    <P>• Receive fill status notifications (RxFill).</P>
                    <P>• Request and respond to change prescriptions (RxChangeRequest, RxChangeResponse).</P>
                    <P>• Request to cancel prescriptions (CancelRx).</P>
                    <P>• Request and respond to renew prescriptions (RxRenewalRequest, RxRenewalResponse).</P>
                    <P>We believe the transactions above are an appropriate starting place to include race and ethnicity in the electronic prescribing certification criterion. We will continue to monitor changes to the SCRIPT standard for additional updates to transactions to include race and ethnicity data fields.</P>
                    <P>We invite comments on this proposal and request information on whether there are other SCRIPT transactions that include data fields for race and ethnicity we should consider specifying to enable exchange of race and ethnicity data with providers in pharmacy settings.</P>
                    <HD SOURCE="HD3">Base EHR Definition</HD>
                    <P>We note that, given our proposal in section III.B.9.b. to include the proposed “real-time prescription benefit” certification criterion in § 170.315(b)(4) in the Base EHR definition in § 170.102, we have also proposed to add the “electronic prescribing” certification criterion in § 170.315(b)(3) to the Base EHR definition. Please see section III.B.9.b. of this proposed rule for further details on this proposal.</P>
                    <HD SOURCE="HD3">Multi-Factor Authentication</HD>
                    <P>We propose in § 170.315(b)(3)(ii)(G) that, on and after January 1, 2028, a Health IT Module certified to § 170.315(b)(3) must meet the multi-factor authentication (MFA) requirements specified in § 170.315(d)(13)(ii) for user-facing authentication. We believe this update is in line with industry information security best practice for an important authentication use case in health IT, and that it is necessary to help better protect electronic health information. We refer readers to section III.B.17 for our proposal to revise our MFA certification criterion § 170.315(d)(13) and for background on the user level authentication use case we are targeting with this requirement.</P>
                    <BILCOD>BILLING CODE 4150-45-P</BILCOD>
                    <GPH SPAN="3" DEEP="640">
                        <PRTPAGE P="63529"/>
                        <GID>EP05AU24.000</GID>
                    </GPH>
                    <BILCOD>BILLING CODE 4150-45-C</BILCOD>
                    <PRTPAGE P="63530"/>
                    <HD SOURCE="HD3">9. New Real-Time Prescription Benefit Criterion</HD>
                    <HD SOURCE="HD3">a. Background</HD>
                    <P>
                        The increasing costs of prescription drugs have long been a concern for patients, providers, and policymakers.
                        <SU>51</SU>
                        <FTREF/>
                         Increased drug costs can have several negative consequences for patients, including limited access to healthcare,
                        <SU>52</SU>
                        <FTREF/>
                         lower healthcare use,
                        <SU>53</SU>
                        <FTREF/>
                         medication nonadherence 
                        <E T="51">54 55</E>
                        <FTREF/>
                         and financial stress, especially among underserved,
                        <SU>56</SU>
                        <FTREF/>
                         uninsured and underinsured 
                        <SU>57</SU>
                        <FTREF/>
                         populations. Merely having health insurance coverage does not necessarily confer medication affordability on patients.
                        <SU>58</SU>
                        <FTREF/>
                         These challenges continue to be the focus of legislation, such as the Inflation Reduction Act of 2022 (Pub. L. 117-169, August 16, 2022), which includes several provisions that are expected to decrease prescription drug costs and improve access to prescription drugs for the more than 65 million Americans enrolled in the Medicare program, including allowing Medicare to directly negotiate prescription drug prices for the first time, eliminating cost sharing for adult vaccines, capping out-of-pocket costs for insulin, and capping Part D enrollee out-of-pocket spending at $2,000 annually starting in 2025 (see sections 11406, 11401, 1194, and 11201). E. O. 14087, Lowering Prescription Drug Costs for Americans, directed further actions to lower the cost of prescription drugs.
                    </P>
                    <FTNT>
                        <P>
                            <SU>51</SU>
                             A.S. Kesselheim, J. Avorn, A. Sarpatwari, The high cost of prescription drugs in the United States: origins and prospects for reform. JAMA, 316 (8) (2016), pp. 858-871.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>52</SU>
                             Daher, Al Rifai, M., Kherallah, R. Y., Rodriguez, F., Mahtta, D., Michos, E. D., Khan, S. U., Petersen, L. A., &amp; Virani, S. S. (2021). Gender disparities in difficulty accessing healthcare and cost-related medication non-adherence: The CDC behavioral risk factor surveillance system (BRFSS) survey. Preventive Medicine, 153, 106779-106779. 
                            <E T="03">https://www.ncbi.nlm.nih.gov/pmc/articles/PMC9291436/.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>53</SU>
                             Roebuck, Liberman, J. N., Gemmill-Toyama, M., &amp; Brennan, T. A. (2011). Medication adherence leads to lower health care use and costs despite increased drug spending. Health Affairs, 30(1), 91-99. 
                            <E T="03">https://doi-org.ezproxyhhs.nihlibrary.nih.gov/10.1377/hlthaff.2009.1087.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>54</SU>
                             SG Morgan, A. Lee. Cost-related non-adherence to prescribed medicines among older adults: a cross-sectional analysis of a survey in 11 developed countries. BMJ Open, 7 (1) (2017), Article e014287.
                        </P>
                        <P>
                            <SU>55</SU>
                             DiMatteo MR, Giordani PJ, Lepper HS, Croghan TW. Patient adherence and medical treatment outcomes: a meta-analysis. Med Care. 2002; 40 (9): 794-811.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>56</SU>
                             Whaley C, Reed M, Hsu J, Fung V (2015) Functional Limitations, Medication Support, and Responses to Drug Costs among Medicare Beneficiaries. PLoS ONE 10(12): e0144236. 
                            <E T="03">https://doi.org/10.1371/journal.pone.0144236.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>57</SU>
                             Collins SR, Rasmussen PW, Beutel S, Doty MM. The problem of underinsurance and how rising deductibles will make it worse: findings from the Commonwealth Fund Biennial Health Insurance Survey, 2014. New York: Commonwealth Fund; 2015.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>58</SU>
                             Zhao, J., Zheng, Z., Han, X., Davidoff, A. J., Banegas, M. P., Rai, A., Jemal, A., &amp; Yabroff, K. R. (2019). Cancer History, Health Insurance Coverage, and Cost-Related Medication Nonadherence and Medication Cost-Coping Strategies in the United States. Value in health: the journal of the International Society for Pharmacoeconomics and Outcomes Research, 22(7), 762-767. 
                            <E T="03">https://doi.org/10.1016/j.jval.2019.01.015.</E>
                        </P>
                    </FTNT>
                    <P>
                        Research also suggests provider-patient discussions during clinical encounters about costs and affordability may lead to an overall reduction in out-of-pocket costs.
                        <SU>59</SU>
                        <FTREF/>
                         Real-time prescription benefit tools empower providers and their patients to compare the patient-specific cost of a drug to the cost of a suitable alternative, compare prescription costs at different pharmacy locations, view information about out-of-pocket costs, and learn whether a specific drug is subject to utilization management restrictions such as prior authorization, step therapy, or quantity limits. We believe, when appropriate, use of these tools can allow the provider and patient to choose among clinically acceptable alternative medication treatments while weighing coverage and point-in-time costs. Access to this data within the electronic prescribing workflow may also help to reduce provider burden associated with coverage determination and prior authorization appeals. We believe widespread adoption of such tools, along with increased awareness of drug cost information among patients and providers will likely spur more robust evaluations over time.
                    </P>
                    <FTNT>
                        <P>
                            <SU>59</SU>
                             Carroll JK, Farah S, Fortuna RJ, et al. Addressing medication costs during primary care visits: a before-after study of team-based training. Ann Intern Med. 2019;170(suppl 9): S46-S53. doi:10.7326/M18-2011.
                        </P>
                    </FTNT>
                    <P>Section 119 of Title I, Division CC of the Consolidated Appropriations Act of 2021, (Pub. L. 116-260, December 27, 2020) (CAA, 2021), requires 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) also amended the definition of a “qualified electronic health record” in section 3000(13) of the Public Health Service Act (PHSA) to specify that a qualified electronic health record “includes, or is capable of including, a real-time benefit tool that conveys patient-specific real-time cost and coverage information with respect to prescription drugs that, with respect to any health information technology certified for electronic prescribing, the technology shall be capable of incorporating the information described in clauses (i) through (iii) of paragraph (2)(B) of section 1860D-4(o) of the Social Security Act.” The information specified in (2)(B)(i)-(iii) of section 1860D-4(o) of the Social Security Act, as added by section 119(a) of the CAA, 2021, is:</P>
                    <P>• A list of any clinically appropriate alternatives to such drug included in the formulary of such plan.</P>
                    <P>• Cost-sharing information and the negotiated price for such drug and such alternatives at multiple pharmacy options, including the individual's preferred pharmacy and, as applicable, other retail pharmacies and a mail order pharmacy; and</P>
                    <P>• The formulary status of such drug and such alternatives and any prior authorization or other utilization management requirements applicable to such drug and such alternatives included in the formulary of such plan.</P>
                    <P>The provision further specifies that the change to the definition of a “qualified electronic health record” shall be implemented “at a time specified by the Secretary but not before the Secretary adopts a standard for such tools.”</P>
                    <P>In the HTI-1 Proposed Rule (88 FR 23848 through 23855), we included a request for information (RFI) about issues related to establishing a real-time prescription benefit certification criterion utilizing the NCPDP Real-Time Prescription Benefit (RTPB) standard, and ways in which the Program could ensure real-time prescription benefit capabilities are implemented effectively for providers. We received many comments on this RFI and appreciate the input provided by commenters.</P>
                    <P>In order to implement section 119(b) of the CAA, 2021, we propose to establish a “real-time prescription benefit” health IT certification criterion in § 170.315(b)(4) and to include this certification criterion in the Base EHR definition in § 170.102(3)(iv).</P>
                    <HD SOURCE="HD3">b. Revision to the Base EHR Definition and Health IT Module Dependent Criteria Requirements</HD>
                    <P>
                        As noted above, section 119(b) of the CAA, 2021, amended the definition of a “qualified electronic health record” (Qualified EHR) in section 3000(13) of the PHSA to specify that a qualified electronic health record “includes, or is capable of including, a real-time benefit tool that conveys patient-specific real-time cost and coverage information with respect to prescription drugs.” In the 2014 Edition Final Rule, we established the term “Base EHR,” based on the Qualified EHR definition in PHSA 
                        <PRTPAGE P="63531"/>
                        section 3000(13), for use within the Program (77 FR 54262). We define Base EHR in § 170.102, and this definition currently includes certification criteria under the Program that align with the elements of the Qualified EHR definition in the PHSA.
                    </P>
                    <P>Given that the statutory definition of Qualified EHR is implemented in regulation through the Base EHR definition in § 170.102, we believe it is necessary to propose to update the Base EHR definition consistent with Congress' modification of the statutory definition of Qualified EHR to address real-time benefit tool functionality. Specifically, consistent with PHSA section 3000(13), as amended by section 119(b) of the CAA, 2021, we propose to revise the Base EHR definition in § 170.102 to add paragraph (3)(iv) to include the real-time prescription benefit certification criterion proposed in § 170.315(b)(4) on and after January 1, 2028. We believe including the “real-time prescription benefit” certification criterion as part of the Base EHR definition will increase the use of real-time prescription benefit tools and promote widespread adoption which will help to lower drug costs for Medicare beneficiaries, consistent with section 119 of the CAA. Use of real-time prescription benefit tools enable Medicare providers and enrollees to make cost-informed decisions about prescriptions, and a standardized approach will ensure that critical drug and drug price data is available to providers when they need it.</P>
                    <P>We note that in the Part D and Health IT Standards Final Rule CMS finalized to require Part D plan sponsors to adhere to NCPDP RTPB standard version 13 as part of requirements to provide a prescriber real-time benefit tool by January 1, 2027 in the Part D and Health IT Standards Final Rule (89 FR 51259 and 51260). We request comment on whether we should seek to align the date when the “real-time prescription benefit” certification criterion in § 170.315(b)(4) would be effective for the Base EHR definition (proposed to be January 1, 2028) with the date finalized in the Part D and Health IT Standards Final Rule for Part D plan sponsors' real-time benefit tools to adhere to the NCPDP RTPB standard version 13 (January 1, 2027) (89 FR 51260).</P>
                    <P>The amended definition of a Qualified EHR in PHSA section 3000(13)(c) further specifies that “with respect to any health information technology certified for electronic prescribing, the technology shall be capable of incorporating the information described in clauses (i) through (iii) of paragraph (2)(B).” We interpret this provision to mean, for the purposes of the Program, that any health IT presented for certification for electronic prescribing capabilities should also be capable of incorporating the real-time benefit information specified in clauses (i) through (iii) of paragraph (2)(B) of section 1860D-4(o) of the Social Security Act, as described above.</P>
                    <P>Real-time prescription benefit functionality is closely related to electronic prescribing functionality, which provides the basic workflow within which a provider may seek to identify information about a patient's coverage for a certain prescription before transmitting that electronic prescription to the pharmacy. In most cases, we expect health IT developers seeking certification to § 170.315(b)(4) will already be certified to § 170.315(b)(3), though there will be some variation due to the modularity of Program criteria. Accordingly, we propose to revise § 170.550(g) to add paragraph (g)(6) in order to require that any developer that obtains certification for the “electronic prescribing” certification criterion in § 170.315(b)(3) must also obtain certification for the proposed “real-time prescription benefit” criterion in § 170.315(b)(4).</P>
                    <P>
                        While we propose to establish this dependency with the “electronic prescribing” certification criterion, this certification criterion is not included as part of the current Base EHR definition in § 170.102. Although electronic prescribing is a widely used and fundamental capability of health IT, we have, to date, not included this certification criterion in the Base EHR definition for several reasons. First, the Qualified EHR definition in section 3000(13) of the PHSA does not specify electronic prescribing as a required element of a Qualified EHR and we have generally sought to limit the Base EHR definition in § 170.102, which implements the Qualified EHR definition, to those capabilities that are required for the Qualified EHR definition by statute. Second, many health care providers have historically been required to adopt certified technology for electronic prescribing in order to meet the requirements of the Medicare EHR Incentive Programs, now known as the Medicare Promoting Interoperability Program and the Promoting Interoperability performance category of the Merit-Based Incentive Payment System (MIPS).
                        <SU>60</SU>
                        <FTREF/>
                         Objectives and measures for eligible professionals, eligible hospitals, and CAHs under these programs have included measures related to electronic prescribing throughout the course of the programs. Section 1848(o)(2)(A)(i) of the Social Security Act also requires that demonstration of use of certified EHR technology in a meaningful manner by an eligible professional “shall include the use of electronic prescribing.”
                    </P>
                    <FTNT>
                        <P>
                            <SU>60</SU>
                             The Medicaid EHR Incentive Program sunset in 2021 (84 FR 42592).
                        </P>
                    </FTNT>
                    <P>However, given our proposal to include the proposed “real-time prescription benefit” certification criterion in § 170.315(b)(4) in the Base EHR definition, we believe it is also appropriate to add the “electronic prescribing” certification criterion in § 170.315(b)(3) to the Base EHR definition. While we previously did not include this capability in the Base EHR definition for the reasons described above, we believe that the inclusion of closely related “real-time prescription benefit” functionality in § 170.315(b)(4) necessitates the inclusion of electronic prescribing functionality. We therefore propose to include the “electronic prescribing” certification criterion in § 170.315(b)(3) within the Base EHR definition in § 170.102. We further propose to specify that this criterion would be effective for the Base EHR definition on and after January 1, 2028, which aligns with the date when the proposed “real-time prescription benefit” certification criterion in § 170.315(b)(4) would be effective for the Base EHR definition.</P>
                    <P>We request comment on these proposals, especially regarding the impact of these proposals on health IT developers seeking to ensure their products meet the Base EHR definition that are not currently separately certified to the “electronic prescribing” criterion. We seek information on the additional burden to developers of requiring the “electronic prescribing” certification criterion as part of the Base EHR definition in addition to the proposed “real-time prescription benefit” certification criterion. We also request comment on the implications for interoperability of electronic prescribing if we were to finalize our proposal to include the “real-time prescription benefit” certification criterion within the Base EHR definition but not finalize our proposal to include the “electronic prescribing” certification criterion in the Base EHR definition.</P>
                    <P>
                        Lastly, we request comment on the impact this proposed policy would have on any health care providers participating in the Medicare Promoting Interoperability Program and the Promoting Interoperability performance category of the Merit-Based Incentive Payment System (MIPS) who have historically been able to claim an exclusion from electronic prescribing 
                        <PRTPAGE P="63532"/>
                        measures in these programs, and, as a result have not adopted certified health IT for electronic prescribing in order to complete the actions associated with these measures. The definitions of certified EHR technology at 42 CFR 495.4 and 42 CFR 414.1305, which define technology requirements for these programs, cross-reference the Base EHR definition at 45 CFR 171.102. Thus, as a result of the statutory change implemented by Congress, and if our proposals to add these certification criteria to the Base EHR definition are finalized, all providers participating in these programs would have to have at a minimum, health IT certified to the proposed “real-time prescription benefit” certification criterion and the “electronic prescribing” certification criterion. This would include participants that currently successfully participate in these programs without possessing certified health IT that supports these capabilities. We request comment on whether finalizing these proposals would impose significant burden on these health care providers.
                    </P>
                    <HD SOURCE="HD3">c. Real-Time Prescription Benefit Standard</HD>
                    <P>
                        We propose in § 170.315(b)(4)(i) that a Health IT Module certified to the proposed “real-time prescription benefit” certification criterion must enable a user to perform certain real-time prescription benefit electronic transactions in accordance with at least one of the versions of the standard adopted in § 170.205(c). Under this paragraph, ONC adopted the NCPDP RTPB standard version 13 
                        <SU>61</SU>
                        <FTREF/>
                         on behalf of HHS in § 170.205(c)(1) in the Part D and Health IT Standards Final Rule, which appeared in the 
                        <E T="04">Federal Register</E>
                         on June 17, 2024 (89 FR 51238 through 51265). If we adopt subsequent versions of the NCPDP RTPB standard in § 170.205(c), our proposal to require the use of at least one of the versions of the standard adopted in § 170.205(c) would enable health IT developers to use any version of the standard adopted under this paragraph, unless we specify an adoption “expiration” date which indicates a certain version of the standard may no longer be used after that date.
                    </P>
                    <FTNT>
                        <P>
                            <SU>61</SU>
                             
                            <E T="03">See https://standards.ncpdp.org/Access-to-Standards.aspx.</E>
                        </P>
                    </FTNT>
                    <P>The NCPDP RTPB standard version 13 enables the exchange of patient eligibility, product coverage, and benefit financials for a chosen product and pharmacy, and identifies coverage restrictions and alternatives when they exist. The benefits of the more recent NCPDP RTPB standard version 13 relative to NCPDP RTPB standard version 12 include improvements to the NCPDP RTPB Patient Segment, Product and Alternative Product Segments, and new elements, new values, and updated values to the schema, as well as administrative corrections that support consistency and clarity.</P>
                    <P>Because the NCPDP RTPB standard is relatively new and not yet widely implemented, we expect additional enhancements and improvements to the standard over time as more health IT developers adopt and implement the standard and more exchange partners engage in the standards development process with NCPDP. We encourage developers to remain familiar with updates occurring in newer versions of the NCPDP RTPB standard.</P>
                    <HD SOURCE="HD3">d. Sending and Receiving Real-Time Prescription Benefit Information</HD>
                    <P>In order to execute real-time prescription benefit checks in accordance with the NCPDP RTPB standard version 13, a provider originates the request for prescription benefit information for a specific patient from within their health IT. In return, a processor, pharmacy benefit manager, or adjudicator provides the appropriate response. We propose in § 170.315(b)(4)(i) that a Health IT Module certified to the “real-time prescription benefit” criterion must enable a user to perform specified transactions in accordance with at least one of the versions of the standard adopted in § 170.205(c) (where we have adopted the NCPDP RTPB standard version 13), as well as one of the versions of the standard in § 170.207(d)(1) (where we have adopted RxNorm) and the standard in § 170.207(d)(2) (where we have cross-referenced National Drug Codes (NDC)).</P>
                    <P>We propose in § 170.315(b)(4)(i)(A) that a Health IT Module certified to the proposed criterion must enable a user to request patient-specific prescription benefit information, estimated cost information, and therapeutic alternatives, in accordance with the RTPBRequest transaction. We propose in § 170.315(b)(4)(i)(B) that a Health IT Module certified to the proposed criterion must enable a user to receive patient-specific prescription benefit information, estimated cost information, and therapeutic alternatives in response to a request, in accordance with the RTPBResponse transaction. RTPBRequest and RTPBResponse transactions are determined by patient, benefit, and product-specific information. Each request and response are unique with information conditioned on factors associated with each transaction. Health IT Modules certified to the proposed certification criterion should support transaction segments and associated data elements necessary to reflect both the information needed for a successful RTPBRequest and the information contained in a detailed RTPBResponse. As such, a Health IT Module must have the capability to send and receive both mandatory and situational transaction segments and associated data elements for RTPBRequests and RTPBResponse transactions as specified in NCPDP RTPB standard version 13. Finally, we propose in § 170.315(b)(4)(i)(C) that a Health IT Module certified to the proposed criterion must enable a user to be notified of errors when there is a problem with a real-time prescription benefit transaction, in accordance with the RTPBError transaction.</P>
                    <P>We request comments on these proposals and whether we should consider other capabilities for the certification criterion in the future.</P>
                    <HD SOURCE="HD3">Use of XML Format</HD>
                    <P>We propose in § 170.315(b)(4)(i) that a Health IT module certified to the criterion must enable a user to perform the specified transactions using the XML format. While the NCPDP RTPB standard version 13 supports both EDI and XML formats, in response to the RFI included in the HTI-1 Proposed Rule (88 FR 23746), we received many comments in support of testing the XML format of the RTPB standard alone or with the EDI format as optional. Additionally, commenters recommended that ONC should test the format each individual health IT developer has chosen for its own system to be tested in. Some commentors also shared a desire to move away from XML and EDI altogether, preferring the JSON format instead, noting industry plans for the future retirement of XML and EDI. One commenter suggested certification in either format, with requirements that health IT be capable of demonstrating translation capabilities between EDI and XML.</P>
                    <P>After considering these comments, we believe that proposing to only require use of the XML format will simplify testing for health IT developers. ONC will continue to monitor syntax and format updates and development for real-time benefit transactions and associated standards.</P>
                    <HD SOURCE="HD3">e. Additional Topics</HD>
                    <HD SOURCE="HD3">Display</HD>
                    <P>
                        We propose in § 170.315(b)(4)(ii) that a Health IT Module certified to the criterion must display to a user in 
                        <PRTPAGE P="63533"/>
                        human readable format patient-specific prescription benefit information, estimated cost information, and therapeutic alternatives in accordance with at least one of the versions of the standard in § 170.205(c) (where we have adopted NCPDP RTPB standard version 13). The ability to display RTPB data provides access to this information and is essential for a user to be able to use the information to inform shared decision-making as the provider and patient determine the treatment that will be best for them.
                    </P>
                    <HD SOURCE="HD3">Scope</HD>
                    <P>
                        The NCPDP RTPB standard version 13 supports real-time prescription benefit requests and responses for a variety of items manufactured for sale such as medications, vaccines, and medical devices or supplies.
                        <SU>62</SU>
                        <FTREF/>
                         While the majority of products covered by an individual's pharmacy benefit will be medications, Part D drugs, as defined at 42 CFR 423.100, can include prescription medications, vaccines, and supplies associated with the injection of insulin (
                        <E T="03">e.g.,</E>
                         syringes, alcohol pads, gauze), and are represented by RXCUIs 
                        <SU>63</SU>
                        <FTREF/>
                         on the formulary file.
                    </P>
                    <FTNT>
                        <P>
                            <SU>62</SU>
                             
                            <E T="03">See https://www.ncpdp.org/Access-to-Standards.aspx.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>63</SU>
                             An RXCUI is a machine-readable code or identifier that points to the common meaning shared by the various source names grouped and assigned to a particular concept. More information can be found at 
                            <E T="03">https://www.nlm.nih.gov/research/umls/rxnorm/overview.html.</E>
                        </P>
                    </FTNT>
                    <P>In the HTI-1 Proposed Rule we requested comment on the appropriate scope for a “real-time prescription benefit” certification criterion, including whether a “real-time prescription benefit” certification criterion should require support for products that are not defined as medications but may also be included in a RTPB transaction, namely vaccines and medical devices or supplies (87 FR 23853). We received several comments in response to our request for information on this topic, with several commenters encouraging an initial focus on medications for the certification criterion.</P>
                    <P>
                        In addition to medications, we believe it is important to require Health IT Modules certified to the “real-time prescription benefit” criterion to be able to support vaccines, and note that under Part D regulations and guidance, plans include most commercially available vaccines on their formularies.
                        <SU>64</SU>
                        <FTREF/>
                         However, we are not proposing to include devices and supplies in the proposed certification criterion at this time. We note that the NCPDP RTPB standard version 13 does yet not support the FDA Unique Device Identification System unique device identifiers (UDIs), which are identified as the standard for the Unique Device Identifier—Implantable data element in the Medical Devices data class in the USCDI.
                        <SU>65</SU>
                        <FTREF/>
                         Additionally, devices covered under a pharmacy benefit may be defined as a drug under Section 201(g) of the Federal Food, Drug, and Cosmetic Act (21 U.S.C. 321(h)) rather than a device under Section 201(h) and therefore are not assigned a Unique Device Identifier for Implantable Devices. ONC will continue to monitor advancements to the NCPDP RTPB standard to support unique identifiers for devices, any related developments at the FDA, and updates to the standardization and exchange of device and supplies data.
                    </P>
                    <FTNT>
                        <P>
                            <SU>64</SU>
                             
                            <E T="03">See</E>
                             “Medicare Prescription Drug Benefit Manual: Chapter 6—Part D Drugs and Formulary Requirements” 30.2.7 at 
                            <E T="03">https://www.cms.gov/medicare/prescription-drug-coverage/prescriptiondrugcovcontra/downloads/part-d-benefits-manual-chapter-6.pdf.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>65</SU>
                             
                            <E T="03">See</E>
                             USCDI v4: 
                            <E T="03">https://www.healthit.gov/isa/taxonomy/term/821/uscdi-v4.</E>
                        </P>
                    </FTNT>
                    <P>In summary, we propose in § 170.315(b)(4)(iii) that scope of the criterion is limited to medications and vaccines covered by a pharmacy benefit. We invite comments on this proposal.</P>
                    <HD SOURCE="HD3">Formulary and Benefit</HD>
                    <P>In the HTI-1 Proposed Rule, we requested comment on whether we should further explore capabilities for Health IT Modules to support access to formulary and benefits information and provided detail about how access to formulary and benefits information was previously supported within the Program. We noted that in the 2015 Edition Final Rule, ONC included a “Drug-formulary and preferred drug list checks” certification criterion in § 170.315(a)(10). However, ONC did not adopt the proposed NCPDP Formulary and Benefit standard version 3.0 to support this criterion due to comments received in response to the 2015 Edition Proposed Rule (80 FR 16821). The drug formulary and preferred drug list checks § 170.315(a)(10) certification criterion was later removed from the Program in the ONC Cures Act Final Rule (85 FR 25660) because this functionality was widely available, and there was not sufficient reason to justify the burden on developers and providers of meeting Program compliance requirements specific to this criterion. We noted that updates, enhancements, and corrections have been made to the NCPDP Formulary and Benefit standard since we considered adopting version 3.0, and many of these updates addressed concerns commenters expressed previously (87 FR 23854).</P>
                    <P>Subsequently, in the Part D and Health IT Standards Final Rule, we finalized adoption of NCPDP Formulary and Benefit standard version 60 in § 170.205(u) (89 FR 51260), reflecting an aligned approach with the Part D Program to adoption of standards that support electronic prescribing. In the same rulemaking, CMS finalized to cross-reference NCPDP Formulary and Benefit standard version 60 in the requirements for transmitting formulary and benefit information between prescribers Part D sponsors proposed at 42 CFR 423.160(b)(3) (89 FR 51250 and 51251). However, we did not make any updates to the Program to incorporate the proposed Formulary and Benefit standard as part of certification criteria.</P>
                    <P>In response to our request for comment in the HTI-1 Proposed Rule, some commenters supported incorporation of capabilities to access formulary and benefits information within the Program based on the NCPDP Formulary and Benefit standard. However, many stated that a certification criterion based on the standard is not necessary as this functionality is already widespread in the industry due to existing CMS regulatory requirements. Furthermore, these commenters stated that a criterion based on the NCPDP Formulary and Benefit standard may limit innovation around other approaches to obtaining formulary and benefit information currently being explored by the industry.</P>
                    <P>We have considered the comments received in response to the RFI and have determined not to propose new functionality related to formulary and benefits information within the Program at this time. We also note that we have proposed to adopt the HL7 FHIR Da Vinci—Payer Data Exchange (PDex) US Drug Formulary Implementation Guide, version 2.0.1—STU 2, in § 170.215(m)(i) in this proposed rule and have referenced this standard as part of the “patient access API” certification criterion proposed in § 170.315(g)(30)(iii).</P>
                    <HD SOURCE="HD3">Negotiated Price</HD>
                    <P>
                        Section 1860D-4(o)(2)(B)(ii) of the Social Security Act, as added by section 119(a) of the CAA, 2021, specifically requires real-time benefit tools capable of providing information on “cost-sharing information and the negotiated price” for drugs and alternatives. However, we note that we have not proposed to include negotiated price in the proposed § 170.315(b)(4) certification criterion. The NCPDP RTPB 
                        <PRTPAGE P="63534"/>
                        standard version 13 does not include fields to support the exchange of negotiated price. We solicited comments regarding negotiated price in response to the RFI, and commenters expressed strong disapproval for the inclusion of negotiated price in RTBTs. Additionally, concerns were shared that plan negotiated prices may be confusing to providers and patients and are not likely to assist or improve the utility or usability of technology certified to a real-time prescription benefit certification criterion. We also note that CMS does not require the exchange of negotiated price by Part D sponsors when implementing an electronic real-time benefit tool. NCPDP RTPB standard version 13, which we have proposed to incorporate into the proposed “real-time prescription benefit” certification criterion, is the best available standard for use currently to provide patient specific cost-sharing information. Unfortunately, we have not identified a standard or any consistent approach to deliver reliable negotiated price information in real-time. ONC will continue to work with CMS and other interested parties to determine how negotiated price information may be made available and what technical approaches exist to support transparency in negotiated prices of drugs.
                    </P>
                    <HD SOURCE="HD3">10. Electronic Health Information (EHI) Export—Single Patient EHI Export Exemption</HD>
                    <HD SOURCE="HD3">a. Background</HD>
                    <P>In the ONC Cures Act Final Rule (85 FR 25690 through 25700), we finalized a new certification criterion in § 170.315(b)(10) for Electronic Health Information (EHI) Export. The certification criterion's conformance requirements were intended to support two contexts in which we believe that all EHI produced and electronically managed by a developer's technology should be made readily available for export as a capability of certified health IT. First, we finalized in § 170.315(b)(10)(i) that health IT certified to this criterion must support single patient EHI export upon a valid request by a patient or a user on the patient's behalf. Second, we finalized in § 170.315(b)(10)(ii) that the product would support the export of all EHI when a health care provider chooses to transition or migrate information to another health IT system. Furthermore, we established in § 170.402(a)(4), as part of the Assurances Condition of Certification requirement, that any certified Health IT Module that is part of a health IT product which electronically stores EHI must certify to the certification criterion in § 170.315(b)(10).</P>
                    <P>For the single patient EHI export functionality, we also established in § 170.315(b)(10)(i)(B) that a user must be able to execute this capability at any time the user chooses and without subsequent developer assistance to operate. Subsequently, ONC has heard from developers that some certified Health IT Modules act primarily as intermediaries between systems and, through integration, function without any direct human interaction. As an example, a Health IT Module may facilitate public health reporting by processing existing EHI into a required format for report submission without any user interactions. In such circumstances, a human user may not interact with the certified Health IT Module itself; and even though the Health IT Module stores EHI or causes EHI to be stored, this EHI may be a differently formatted copy of the EHI that already exists in a different, yet integrated, certified Health IT Module.</P>
                    <HD SOURCE="HD3">b. Proposal for EHI Export</HD>
                    <P>ONC continues to believe that access to EHI export in such circumstances is critical. However, we recognize the potential burden in requiring the technology development and implementation of functionality to execute the capability of single patient EHI export at any time the user chooses and without subsequent developer assistance to operate, as established in § 170.315(b)(10)(i)(B), for those products that act primarily as intermediaries between systems and, through integration, function without any direct human interaction.</P>
                    <P>
                        Therefore, we propose to exempt Health IT Modules that act primarily as intermediaries between systems and, through integration, function without any direct human interaction from the requirement in § 170.315(b)(10)(i)(B) to provide functionality without subsequent developer assistance to operate. We propose this new exemption in § 170.315(b)(10)(i)(F), and we caveat the availability of this exemption in two ways. First, in § 170.315(b)(10)(i)(F)(
                        <E T="03">1</E>
                        ) we propose to require that the EHI stored, or caused to be stored, by the Health IT Module certified to § 170.315(b)(10) must be a copy, whether in the same or another format, of EHI also stored by another Health IT Module with which the Health IT Module certified to § 170.315(b)(10) is integrated. Second, in order to ensure that such an exemption is appropriately limited to Health IT Modules that primarily function without user interaction and from which users would only rarely seek single patient EHI export consistent with § 170.315(b)(10)(i), we further propose in § 170.315(b)(10)(i)(F)(
                        <E T="03">2</E>
                        ) that any Health IT Module for which the developer receives more than 10 requests in the immediately preceding calendar year for a single patient EHI export would no longer qualify for this exemption and would need to provide functionality under § 170.315(b)(10)(i)(B) without subsequent developer assistance to operate. For purposes of this exemption, we clarify that requests for a single patient EHI export would be counted at the product-level rather than the individual instance-level. This means any request made across all deployed settings or deployed instances of the Health IT Module would count towards this proposed threshold. We note that the developer must still meet all other requirements in § 170.315(b)(10), but that such an exemption would allow them flexibility in how single patient EHI export is provided under § 170.315(b)(10)(i), including providing the export with developer assistance similar to how they provide patient population EHI export under § 170.315(b)(10)(ii).
                    </P>
                    <P>We note that the limited circumstance defined here would not be applicable to health information exchanges or networks. ONC believes that patients and users assisting patients have a continued need for access to all single patient EHI, and products in which EHI is aggregated (such as health information exchanges and networks) should facilitate full and unfettered access to such information.</P>
                    <P>We welcome comments on this proposal, including on the threshold of 10 requests across all deployed settings (or deployed instances) of the Health IT Module per calendar year to qualify for the exemption.</P>
                    <HD SOURCE="HD3">c. Proposal for Associated Assurances Requirements for Single Patient EHI Export Exemption</HD>
                    <P>
                        To ensure that a developer of certified health IT with a Health IT Module certified to § 170.315(b)(10) does not inappropriately use the proposed exemption for single patient EHI export in § 170.315(b)(10)(i)(F) to block information or inhibit the appropriate access, exchange, and use of EHI, we propose a new Assurances Maintenance of Certification requirement. We propose in § 170.402(b)(2)(iii) that developers of certified health IT with Health IT Modules certified to § 170.315(b)(10) that claim the exemption proposed in 
                        <PRTPAGE P="63535"/>
                        § 170.315(b)(10)(i)(F) would need to report the number of requests for single patient EHI export on an annual basis to their ONC-ACB(s). Specifically, in § 170.402(b)(2)(iii)(A) we propose that on and after January 1, 2028, a health IT developer of a Health IT Module certified to the certification criterion in § 170.315(b)(10) and meets the requirements of paragraph (b)(10)(i)(F) must report to its ONC-ACB no later than March 1 of each calendar year how many requests it received during the immediately preceding calendar year. We welcome comments on this proposal.
                    </P>
                    <HD SOURCE="HD3">11. Revised End-User Device Encryption Criterion</HD>
                    <HD SOURCE="HD3">a. Background</HD>
                    <P>In the final rule titled “Health Information Technology: Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology, 2014 Edition; Revisions to the Permanent Certification Program for Health Information Technology” (2014 Edition Final Rule) we included end-user device encryption requirements in § 170.315(d)(7) focused on designing EHR technology to secure EHI on end-user devices in accordance with the approach recommend by the Health IT Standards Committee (HITSC) at the time (77 FR 54236). Since finalizing this certification criterion in the 2014 Edition Final Rule, encryption technology has continued to advance significantly, and we have identified a gap in our current requirements, which only include end-user device encryption requirements and exclude server-side encryption requirements.</P>
                    <P>
                        When finalizing our end-user device encryption requirements in § 170.315(d)(7) in the 2014 Edition Final Rule, we posited that end-user device encryption was “more practical, effective and easier to implement” than the general encryption requirement we had finalized originally in the ONC 2011 Edition certification criteria, which included server encryption requirements (77 FR 54236). Encryption technology and availability have significantly improved in the time since the 2014 Edition Final Rule. For example, developers using Microsoft Windows Server version 2016 and later versions have BitLocker disk encryption software readily available, and Linux-based server developers have free and open-source disk encryption utilities like Cryptsetup.
                        <SU>66</SU>
                        <FTREF/>
                         These tools, and others like them, make it easy for server developers to take advantage of the numerous benefits of server encryption.
                    </P>
                    <FTNT>
                        <P>
                            <SU>66</SU>
                             Microsoft documentation explaining how to deploy BitLocker disk encryption on Windows Server 2016 and later: 
                            <E T="03">https://docs.microsoft.com/en-us/windows/security/information-protection/bitlocker/bitlocker-how-to-deploy-on-windows-server.</E>
                             Homepage for the Cryptsetup utility that can be used for Linux hard disk encryption: 
                            <E T="03">https://gitlab.com/cryptsetup/cryptsetup/.</E>
                             Note that these tools would need to be configured to use Approved Security Functions for FIPS PUB 140-2 to meet ONC's proposed server encryption requirements outlined later in this section. Approved Security Functions for FIPS PUB 140-2 are here: 
                            <E T="03">https://csrc.nist.gov/files/pubs/fips/140-2/upd2/final/docs/fips1402annexa.pdf</E>
                            .
                        </P>
                    </FTNT>
                    <P>
                        Encryption of server-side data prevents unauthorized data access in many scenarios, including those involving a server breach, theft, or improper disposal. Mitigating these risks using encryption is a best practice for all server developers and, given the unique characteristics of EHI, is especially important for health IT server developers. EHI is considered one of the most valuable types of personal information for theft because of the breadth of information included in electronic health records and the long shelf life of this information. However, despite its high value, EHI often is not being properly protected, and the problem is getting worse according to data published on the Department of Health and Human Services Office for Civil Rights (OCR) website. Between 2010 and 2022, OCR received 5,144 reports of breaches affecting 500 or more individuals, impacting a total of 394,236,737 individuals.
                        <SU>67</SU>
                        <FTREF/>
                         The frequency of breaches affecting 500 individuals or more has increased significantly over the past few years, with almost two such breaches reported per day in 2022, nearly double the frequency in 2018.
                        <SU>68</SU>
                        <FTREF/>
                         These statistics indicate that vulnerabilities and risks exist in technology storing EHI in the United States. While no single solution can fully protect EHI, data breach risks can be mitigated by encryption of data maintained on servers.
                    </P>
                    <FTNT>
                        <P>
                            <SU>67</SU>
                             
                            <E T="03">See https://ocrportal.hhs.gov/ocr/breach/breach_report.jsf.</E>
                             These numbers are based on breach reports made to OCR as of May 17, 2024.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>68</SU>
                             
                            <E T="03">See https://ocrportal.hhs.gov/ocr/breach/breach_report.jsf.</E>
                             These numbers are based on breach reports made to OCR as of May 17, 2024.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">b. Proposal</HD>
                    <P>To better protect electronic health information stored in Health IT Modules certified under the Program, we propose to clarify the scope of information that needs to be protected in Health IT Modules certified to § 170.315(d)(7) and revise the order and sequence of existing requirements in § 170.315(d)(7) to include new requirements for server-side encryption.</P>
                    <P>First, to clarify the scope of electronic health information that needs to be protected in Health IT Modules certified to § 170.315(d)(7), we propose that on and after January 1, 2026 the information that must be protected within Health IT Modules certified to this revised criterion in § 170.315(d)(7) include all personally identifiable information (PII). This includes, but is not limited to, individually identifiable health information meeting the definition of electronic protected health information in 45 CFR 160.103, regardless of whether the information is held by or for a HIPAA covered entity or entity required to comply with the Privacy Act of 1974 (5 U.S.C. 552a), as amended.</P>
                    <P>Second, we propose to revise existing requirements in § 170.315(d)(7) to include new requirements for server-side encryption and include the PII encryption requirements for servers in a way that maintains our existing end-user device encryption requirements and applies the existing encryption standard and the default settings requirements broadly in one criterion.</P>
                    <P>We propose to change the name of § 170.315(d)(7) to “health IT encryption,” to better describe the end-user and proposed server-side requirements together. We also propose moving our existing end-user device encryption requirements, in § 170.315(d)(7)(i) and (ii), into paragraph § 170.315(d)(7)(i) that expires on January 1, 2026 and is replaced by a new PII encryption requirement for end-user devices in § 170.315(d)(7)(ii) that must be met on and after January 1, 2026.</P>
                    <P>Additionally, we propose including the new server-side encryption requirement in § 170.315(d)(7)(iii) that must be met on and after January 1, 2026. We propose that this new server encryption requirement in § 170.315(d)(7)(iii) state that technology designed to store PII must encrypt the stored PII after use of the technology on those servers stops.</P>
                    <P>
                        We also propose to move the encryption standard and default settings requirements that are currently in § 170.315(d)(7)(i)(A) and (B) respectively into their own higher-level sections in § 170.315(d)(7)(iv) and (v) respectively. Additionally, we propose that these encryption standard and default settings requirements apply to the new server encryption requirement. Pointing to an encryption standard and requiring that default settings be in place for encryption capabilities in § 170.315(d)(7) is consistent with our existing requirements for end-user device encryption, and we believe these 
                        <PRTPAGE P="63536"/>
                        settings are necessary for our proposed new server encryption requirement as well.
                    </P>
                    <P>While certain conformance requirements within the proposed § 170.315(d)(7) have been reorganized, as is outlined in the previous paragraphs, health IT developers with Health IT Modules certified to this criterion will continue to have traceability. If we were to finalize the updates to § 170.315(d)(7) as proposed, developers with Health IT Modules already certified to § 170.315(d)(7) would only need to consider updates to the applicable encryption standards, server-side encryption, and encryption of any non-encrypted PII for the purposes of maintaining Health IT Module certification in the future.</P>
                    <P>
                        The permissible encryption algorithms for our proposed new server encryption requirement are listed in Annex A of The National Institute of Standards and Technology (NIST) Federal Information Processing Standards (FIPS) Publication 140-2, October 12, 2021, which specifies the security requirements for cryptographic modules.
                        <SU>69</SU>
                        <FTREF/>
                         We believe Annex A of FIPS Publication 140-2 is appropriate for our proposed server-side encryption requirements for the same reasons it was considered appropriate for end-user device encryption requirements—it provides clear requirements and flexibility in demonstrating compliance (75 FR 44622). We note that the October 12, 2021, draft is the most recent version of Annex A: Approved Security Functions for FIPS Publication 140-2, and elsewhere in this Proposed Rule at III.B.4, we describe our proposal to revise the standard in § 170.210(a) to include this updated version of Annex A (Draft, October 12, 2021).
                    </P>
                    <FTNT>
                        <P>
                            <SU>69</SU>
                             Annex A of FIPS PUB 140-2: 
                            <E T="03">https://csrc.nist.gov/files/pubs/fips/140-2/upd2/final/docs/fips1402annexa.pdf</E>
                            .
                        </P>
                    </FTNT>
                    <P>
                        Together, we believe that end-user device and server encryption requirements help better protect PII. We clarify that in the context of this certification criterion, a server is a system designed to store PII. We also clarify that in the context of our proposed new server encryption requirement in § 170.315(d)(7)(iii), “stops” means that PII on a server is not actively in use and is not actively moving (
                        <E T="03">i.e.,</E>
                         PII that is not being processed, updated, or otherwise acted upon). We welcome comments on these proposed changes and additions to § 170.315(d)(7).
                    </P>
                    <HD SOURCE="HD3">12. Revised Criterion for Encrypt Authentication Credentials</HD>
                    <HD SOURCE="HD3">a. Background</HD>
                    <P>
                        In the ONC Cures Act Final Rule, we finalized an authentication credential encryption requirement in § 170.315(d)(12) (85 FR 25700). We established an approach that requires health IT developers with Health IT Modules certified to the criterion to be transparent about whether their certified Health IT Module encrypts stored authentication credentials according to industry standards by attesting “yes” or “no.” These “yes” or “no” attestations are made public on ONC's Certified Health IT Product List (CHPL), which is available at 
                        <E T="03">https://chpl.healthit.gov/.</E>
                    </P>
                    <P>
                        We established this approach in acknowledgement that some Health IT Modules certifying to the certification criterion in § 170.315(d)(12) may not be designed to store authentication credentials. We included a provision in § 170.315(d)(12)(ii) that permits health IT developers attesting “no” to explain why their Health IT Module does not support encrypting authentication credentials. We noted in the ONC Cures Act Final Rule that the information regarding the security capabilities of certified health IT provided by the attestation increased transparency and aided health IT users in making informed decisions on how best to protect health information and comply with applicable security regulations (
                        <E T="03">e.g.,</E>
                         the HIPAA Security Rule 
                        <SU>70</SU>
                        <FTREF/>
                        ) (85 FR 25701).
                    </P>
                    <FTNT>
                        <P>
                            <SU>70</SU>
                             The HIPAA Security Rule is located at 45 CFR part 160 and subparts A and C of part 164.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">b. Proposal</HD>
                    <P>We now propose to revise the requirements in the “Encrypt authentication credentials” certification criterion in § 170.315(d)(12). We propose to expire our current “yes” or “no” attestation requirements by moving them to § 170.315(d)(12)(i) and indicating they are applicable only for the time period up to and including December 31, 2025. We propose to replace the attestation requirements by revising § 170.315(d)(12) to include new requirements in § 170.315(d)(12)(ii) that become effective on and after January 1, 2026. Additionally, we propose that a health IT developer may meet the proposed revised certification criterion's requirements by satisfying the new conformance requirements proposed in § 170.315(d)(12)(ii) in lieu of § 170.315(d)(12)(i) prior to paragraph (i)'s December 31, 2025, expiration.</P>
                    <P>With these new requirements, we propose that Health IT Modules designed to store authentication credentials must protect the confidentiality and integrity of their stored authentication credentials. These revisions include requirements in § 170.315(d)(12)(ii)(A) and (B) for authentication credentials to be protected using either encryption and decryption according to the latest version of the Federal Information Processing Standards (FIPS) 140-2 (October 12, 2021) standard in § 170.210(a) or by hashing in accordance with the FIPS 180-4 standard specified in § 170.210(c)(2). As discussed more fully below, we believe that revising § 170.315(d)(12) to require Health IT Modules protect stored authentication credentials according to updated industry standards in § 170.210(a) is necessary and important to improve the security of certified health IT. We note in section III.B.4 in this preamble our proposal to adopt the latest available FIPS Publication 140-2 standard version in § 170.210(a)(3) and expire the old FIPS Publication 140-2 standard in § 170.210(a)(2) as of January 1, 2026.</P>
                    <P>
                        Healthcare data breaches have trended significantly upward in recent years with around two breaches affecting 500 or more individuals reported per day in 2023, nearly double the frequency in 2018.
                        <SU>71</SU>
                        <FTREF/>
                         During this same period, we also found that public CHPL attestation data for Health IT Modules certified to § 170.315(d)(12) indicates that less than 73% of products meeting the Base EHR Definition in § 170.102 included a “yes” attestation to encrypting authentication credentials.
                        <SU>72</SU>
                        <FTREF/>
                         Given that protecting stored authentication credentials according to industry standards is a critical defensive step to help ensure that stolen or leaked authentication credentials are useless to an attacker, we believe it is important to require that a Health IT Module designed to store authentication credentials must protect the confidentiality and integrity of its stored authentication credentials according to § 170.315(d)(12)(ii).
                    </P>
                    <FTNT>
                        <P>
                            <SU>71</SU>
                             
                            <E T="03">https://ocrportal.hhs.gov/ocr/breach/breach_report.jsf.</E>
                             These numbers are based on breach reports made to OCR as of February 12, 2024.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>72</SU>
                             Percentages are based on data retrieved in February 2023 from 
                            <E T="03">https://chpl.healthit.gov/#/</E>
                             search for “Active,” “2015 CURES UPDATE” listings certified to “170.315 (D)(12): ENCRYPT AUTHENTICATION CREDENTIALS (CURES UPDATE) and “170.315 (D)(13): MULTI-FACTOR AUTHENTICATION (CURES UPDATE)”
                        </P>
                    </FTNT>
                    <P>
                        We have chosen to reference the FIPS 140-2 (§ 170.210(a)) and FIPS 180-2 (§ 170.210(c)(2)) standards in § 170.315(d)(12)(ii) because they are the seminal, comprehensive, and most appropriate standards for protecting 
                        <PRTPAGE P="63537"/>
                        sensitive information within computer systems. Referencing these standards also remains consistent with our references to these standards in other certification criteria in our Program.
                    </P>
                    <P>To reflect our proposed revisions to § 170.315(d)(12), we propose to rename the certification criterion from “Encrypt authentication credentials” to “Protect stored authentication credentials.” We believe “protect” is a broader term that more clearly includes methods like hashing that can be used to safeguard stored authentication credentials. In the ONC Cures Act Final Rule we clarified that “encrypting authentication credentials could include password encryption or cryptographic hashing” (85 FR 25700). Despite this clarification, we have received inquiries asking if we consider hashing an acceptable form of “encryption” in the context of this certification criterion. We propose updating the certification criterion title and regulation text to address such concerns. We invite comments on our proposal to revise § 170.315(d)(12) to require a Health IT Module designed to store authentication credentials to protect the confidentiality and integrity of its stored authentication credentials according to updated industry standards.</P>
                    <HD SOURCE="HD3">13. Health IT Modules Supporting Public Health Data Exchange</HD>
                    <HD SOURCE="HD3">a. Background</HD>
                    <P>
                        Public health promotes and protects the health of all people and their communities. To accomplish this mission, public health authorities (PHAs) rely on public health data exchange to acquire the information they need to provide critical functions for society and to keep communities healthy.
                        <SU>73</SU>
                        <FTREF/>
                         However, the nation's public health infrastructure, the technology in place within PHAs, and the methods of data exchange are often siloed, dated, and incapable of quickly providing timely, actionable data needed by PHAs and their partners, resulting in delays in detecting and responding to public health threats.
                        <SU>74</SU>
                        <FTREF/>
                         As documented in numerous studies, and illustrated by the COVID-19 pandemic, there is an ongoing challenge for PHAs at all levels to obtain timely, accurate, representative, and actionable information from electronic health records and other related systems.
                        <SU>75</SU>
                        <FTREF/>
                         However, as noted in a 2022 Government Accountability Office (GAO) report, PHAs do not always have access to—or, often, the ability to share—data needed to address public health needs (emergent or otherwise). This is due, in part, to the lack of common standards utilized in the reported data, variable reporting requirements, limited interoperability of systems, and an inadequate public health data infrastructure.
                        <SU>76</SU>
                        <FTREF/>
                         Addressing these challenges can improve public health response readiness and the nation's healthcare system, enabling better-informed decision making, more comprehensive data analytics, and faster, more coordinated responses to public health threats and emergencies.
                        <E T="51">77 78</E>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>73</SU>
                             
                            <E T="03">https://www.healthit.gov/sites/default/files/page/2023-03/2023-02-08_HITAC_Annual_Report_for_FY22_supplemental_background_research_508_1.pdf.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>74</SU>
                             Data Modernization Initiative Strategic Implementation Plan. December 22, 2021. Available at 
                            <E T="03">https://www.cdc.gov/surveillance/pdfs/FINAL-DMI-Implementation-Strategic-Plan-12-22-21.pdf.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>75</SU>
                             
                            <E T="03">See</E>
                             Public Health Data Modernization: Listening Session on Real-World Testing of 21st Century Cures Act Requirements. Available at 
                            <E T="03">https://www.cdc.gov/surveillance/pubs-resources/dmi-summary/index.html;</E>
                             Alonzo Plough, Gail C Christopher, Equity-Centered Public Health Data Demands New Voices at the Table, Health Affairs (April, 20222) available at 
                            <E T="03">https://www.healthaffairs.org/do/10.1377/forefront.20220427.865970/;</E>
                             Robert Wood Johnson Foundation, Transforming Public Health Data Systems, available at 
                            <E T="03">https://www.rwjf.org/en/insights/our-research/2021/09/transforming-public-health-data-systems.html,</E>
                             and Bipartisan Policy Center, Call to Action for State, Territorial, and Local Policymakers to Move Public Health Forward, December, 2021, available at 
                            <E T="03">https://bipartisanpolicy.org/download/?file=/wp-content/uploads/2021/12/PHF-Call-to-Action-Policymakers-1.pdf.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>76</SU>
                             
                            <E T="03">https://www.gao.gov/products/gao-22-106175.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>77</SU>
                             
                            <E T="03">https://cdn.ymaws.com/www.cste.org/resource/resmgr/pdfs/pdfs2/Driving_PH_Print.pdf.</E>
                        </P>
                        <P>
                            <SU>78</SU>
                             
                            <E T="03">https://www.cdc.gov/surveillance/pdfs/20_319521-D_DataMod-Initiative_901420.pdf.</E>
                        </P>
                    </FTNT>
                    <P>
                        Congress recognized the need to modernize our public health data infrastructure and in response to the COVID-19 pandemic passed legislation that included funding and directives related to such activities. Section 2301 of the American Rescue Plan of 2021 (ARP) (Pub. L. 117-2, enacted March 11, 2021) included funding for information technology, standards-based data, and public health reporting enhancements, including improvements to support standards-based exchange of data related to vaccine distribution and vaccinations.
                        <SU>79</SU>
                        <FTREF/>
                         The Coronavirus Aid, Relief, and Economic Security Act (CARES Act) (Pub. L. 116-136, enacted March 27, 2020) provided funding to support enhancement of public health information system capabilities to address COVID-19 reporting needs.
                        <SU>80</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>79</SU>
                             
                            <E T="03">https://www.congress.gov/117/plaws/publ2/PLAW-117publ2.pdf.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>80</SU>
                             
                            <E T="03">https://www.congress.gov/116/plaws/publ136/PLAW-116publ136.pdf.</E>
                        </P>
                    </FTNT>
                    <P>
                        Several promising Federal efforts have been initiated to address the urgent need to improve public health infrastructure and health IT for public health to enable PHAs to get better and more timely access to the information they need to protect and improve the health of our nation. In this proposed rule, we use the phrase “health IT for public health” to mean hardware, software, integrated technologies or related licenses, IPs, upgrades, or packaged solutions sold as services that are designed to support public health use cases for the electronic creation, maintenance, access, or exchange of public health information, which is consistent with the “health IT” definition in section 13101(5) of the HITECH Act and 45 CFR 170.102. In 2020, CDC launched the Data Modernization Initiative (DMI) to modernize public health data and surveillance infrastructure.
                        <SU>81</SU>
                        <FTREF/>
                         More recently, CDC has released its Public Health Data Strategy (Ph.D.S), which outlines the data, technology, policy, and administrative actions essential to exchange critical core data efficiently and securely across healthcare and public health.
                        <SU>82</SU>
                        <FTREF/>
                         The strategy is designed to describe a path to address gaps in public health data and help the nation become response-ready, promote health equity, and improve health outcomes for all.
                    </P>
                    <FTNT>
                        <P>
                            <SU>81</SU>
                             
                            <E T="03">https://www.cdc.gov/surveillance/data-modernization/basics/index.html.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>82</SU>
                             
                            <E T="03">https://www.cdc.gov/ophdst/public-health-data-strategy/index.html.</E>
                        </P>
                    </FTNT>
                    <P>
                        ONC actively works with CDC and other Federal partners on initiatives that complement, support, and extend CDC's efforts under the Ph.D.S, including USCDI+ Public Health and Helios, a Fast Healthcare Interoperability Resources® (FHIR®) accelerator through HL7®, to help address DMI priorities around data interoperability.
                        <SU>83</SU>
                        <FTREF/>
                         USCDI+ is intended to build upon the core dataset established in the United States Core Data for Interoperability (USCDI), a standardized set of health data classes and data elements for nationwide, interoperable health information exchange, discussed in more detail in section III.B.1 of this proposed rule. We launched USCDI+ Public Health in October 2021 to capture the data needs of public health that extend beyond USCDI to ultimately improve the availability and consistency of data necessary to support various aspects of public health.
                        <SU>84</SU>
                        <FTREF/>
                         In November 2021, HL7 
                        <PRTPAGE P="63538"/>
                        launched Helios in collaboration with CDC and ONC.
                        <SU>85</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>83</SU>
                             
                            <E T="03">https://www.cdc.gov/surveillance/policy-standards/interoperability.html.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>84</SU>
                             
                            <E T="03">https://www.healthit.gov/buzz-blog/health-it/thinking-outside-the-box-the-uscdi-initiative; see also https://www.healthit.gov/topic/interoperability/uscdi-plus.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>85</SU>
                             
                            <E T="03">https://confluence.hl7.org/display/PH/Helios+FHIR+Accelerator+for+Public+Health+Home.</E>
                        </P>
                    </FTNT>
                    <P>
                        The Health Information Technology Advisory Committee (HITAC) was established by the Cures Act and is governed by the provisions of the Federal Advisory Committee Act (FACA) 
                        <SU>86</SU>
                        <FTREF/>
                         which sets forth standards for the formation and use of Federal advisory committees. Section 3002 of the PHSA, as amended by section 4003(e) of the Cures Act, established that the FACA applies to the HITAC and that the HITAC would advise and make recommendations to the National Coordinator on different aspects of standards, implementation specifications, and certification criteria relating to the implementation of a health IT infrastructure, nationally and locally, that advances the electronic access, exchange, and use of health information. The HITAC created a Public Health Data Systems Task Force in 2021 (2021 Task Force) to develop recommendations in response to President Biden's Executive Order on Ensuring a Data-Driven Response to COVID-19 and Future High Consequence Public Health Threats,
                        <SU>87</SU>
                        <FTREF/>
                         which tasked HHS with reviewing the ability of the public health infrastructure to address such threats.
                        <SU>88</SU>
                        <FTREF/>
                         The 2021 Task Force recommended the inclusion of “certification of information systems for both senders and receivers” for public health data.
                        <SU>89</SU>
                        <FTREF/>
                         In 2022, the HITAC convened a second Public Health Data Systems Task Force (2022 Task Force) and directed it to build on the recommendations from the 2021 Task Force to more specifically examine the existing “(f) criteria” within our Program, which certifies health IT for its ability to support various transmissions to PHAs.
                        <SU>90</SU>
                        <FTREF/>
                         The 2022 Task Force found that improvements were needed with respect to the flow of data for public health across the healthcare ecosystem and for robust support of public health in the Program. In particular, the 2022 Task Force highlighted that while the Program has certification criteria related to transmitting data to PHAs, it has not included sufficient real-world testing requirements or the ability of technology used by PHAs to receive and utilize data transmitted according to standards required for certified health IT.
                        <SU>91</SU>
                        <FTREF/>
                         The 2022 Task Force had several recommendations approved by HITAC, including that we establish certification criteria for Health IT Modules supporting public health use cases focused on interoperability functions such as access, exchange, and use of data, and to provide a common floor for addressing public health interoperability needs.
                        <SU>92</SU>
                        <FTREF/>
                         The 2022 Task Force emphasized that the intent of certification criteria related to health IT for public health would be to create a base level of interoperability inclusive of all providers and PHAs and the methods by which data is primarily electronically exchanged—not to restrict public authorities from requesting and receiving data in the manner needed to fulfill their mission.
                    </P>
                    <FTNT>
                        <P>
                            <SU>86</SU>
                             Federal Advisory Committee Act (FACA), Pub. L. 92-463 (1972), codified as amended at, 5 U.S.C. Chapter 10 (formerly 5 U.S.C. App. 2).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>87</SU>
                             
                            <E T="03">https://www.whitehouse.gov/briefing-room/presidential-actions/2021/01/21/executive-order-ensuring-a-data-driven-response-to-covid-19-and-future-high-consequence-public-health-threats/#:~:text=It%20is%20the%20policy%20of,a%20better%20public%20health%20infrastructure.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>88</SU>
                             
                            <E T="03">https://www.healthit.gov/sites/default/files/page/2021-08/2021-07-14_PHDS_TF_2021_HITAC%20Recommendations%20Report_Signed_508_0.pdf.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>89</SU>
                             
                            <E T="03">https://www.healthit.gov/sites/default/files/page/2022-11/2022-11-10_PHDS_TF_Recommendations_Report_Transmittal_Letter_508.pdf.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>90</SU>
                             
                            <E T="03">Id.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>91</SU>
                             
                            <E T="03">https://www.healthit.gov/sites/default/files/facas/2022-11-10_HITAC_Meeting_Notes_508_1.pdf.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>92</SU>
                             
                            <E T="03">Id.</E>
                        </P>
                    </FTNT>
                    <P>In response to these HITAC recommendations in 2021 and 2022 and consistent with the PHSA sections 3001 and 3004 previously described (see section II.A), we are proposing several changes to existing certification criteria as well as the creation of new certification criteria related to health IT for public health. These proposals are responsive to the HITAC recommendations to ONC of increasing the adoption and use of health IT standards for electronic lab reporting, electronic case reporting, and syndromic surveillance, among others. These updates and additions to the certification criteria related to health IT for public health additionally address the HITAC's recommendations to ONC to position CDC, and other Federal partners, to be nimble, responsive, and resilient during the next public health emergency.</P>
                    <P>
                        Additionally, CDC's Advisory Committee to the Director (ACD) recommended that a certification program for health IT for public health would help address core problems with data infrastructure and exchange.
                        <SU>93</SU>
                        <FTREF/>
                         The ACD recommendations include that CDC and ONC should work together to develop and implement a coordinated and phased approach for certifying health IT for public health, grounded in the use of shared data standards. Both the ACD and the HITAC recommendations highlight the shared consensus regarding the need to develop a standards-based certification program to improve the availability and interoperability of important health information between healthcare providers and PHAs.
                    </P>
                    <FTNT>
                        <P>
                            <SU>93</SU>
                             
                            <E T="03">https://www.cdc.gov/about/pdf/advisory/dsw-recommendations-report.pdf.</E>
                        </P>
                    </FTNT>
                    <P>
                        We have also addressed public health data exchange as part of efforts related to the Trusted Exchange Framework and Common Agreement
                        <SU>TM</SU>
                         (TEFCA
                        <SU>TM</SU>
                        ),
                        <SU>94</SU>
                        <FTREF/>
                         which includes public health as a specific “exchange purpose,” and work is underway with the Recognized Coordinating Entity® (RCE
                        <SU>TM</SU>
                        ) to develop a Standard Operating Procedure (SOP) for the public health exchange purpose under TEFCA to support the ability of providers and PHAs to exchange information, as well as standardized, secure interoperability for PHAs to exchange information with each other.
                        <SU>95</SU>
                        <FTREF/>
                         Additionally, we funded the Association of State and Territorial Health Officials (ASTHO) to launch a Health Information Exchange (HIE) and Immunization Information System (IIS) COVID-19 Data Management: Immunization Data Exchange, Advancement and Sharing (IDEAS) program focused on expanding partnerships between state, regional, and local HIEs and IISs.
                        <SU>96</SU>
                        <FTREF/>
                         As a program deliverable, ASTHO conducted an environmental scan focusing on data sharing between HIEs and IISs.
                        <SU>97</SU>
                        <FTREF/>
                         Findings included the need for data exchange partners to use the same vocabularies and coding systems and for the use of a standard messaging format and transmission method for data exchange.
                        <SU>98</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>94</SU>
                             
                            <E T="03">https://www.healthit.gov/topic/interoperability/policy/trusted-exchange-framework-and-common-agreement-tefca#:~:text=The%20overall%20goal%20of%20the,for%20interoperability%20across%20the%20country.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>95</SU>
                             
                            <E T="03">https://rce.sequoiaproject.org/tefca-and-rce-resources/.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>96</SU>
                             
                            <E T="03">https://www.healthit.gov/topic/onc-funding-opportunities/funding-announcements.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>97</SU>
                             
                            <E T="03">https://www.astho.org/globalassets/report/immunization-information-systems-and-health-information-exchanges.pdf.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>98</SU>
                             
                            <E T="03">https://www.astho.org/globalassets/report/immunization-information-systems-and-health-information-exchanges.pdf.</E>
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">b. Regulatory History</HD>
                    <P>
                        In addition to the efforts described above, we have adopted several standards, implementation specifications, and certification criteria related to public health as part of the Program. While the Program itself is voluntary for health IT developers, compliance with Program standards, implementation specifications, and 
                        <PRTPAGE P="63539"/>
                        certification criteria is encouraged through CMS incentive programs. The American Recovery and Reinvestment Act of 2009 (ARRA) (Pub. L. 111-5, enacted February 17, 2009) authorized incentive payments to eligible professionals, eligible hospitals, and critical access hospitals (CAHs) to promote the adoption and meaningful use of CEHRT. In 2011, CMS established the Medicare and Medicaid Electronic Health Record (EHR) Incentive Programs to encourage eligible professionals, eligible hospitals, and CAHs to adopt and make meaningful use of CEHRT. CMS changed the name of the EHR Incentive Programs to the Medicare and Medicaid Promoting Interoperability Programs in April 2018.
                        <SU>99</SU>
                        <FTREF/>
                         The Medicaid Promoting Interoperability Program ended in 2022, and the program is currently known as the Medicare Promoting Interoperability Program for eligible hospitals and CAHs.
                        <SU>100</SU>
                        <FTREF/>
                         The Medicare Promoting Interoperability Program is also a performance category component of CMS' Merit-Based Incentive Payment System (MIPS), a program that determines Medicare payment adjustments.
                    </P>
                    <FTNT>
                        <P>
                            <SU>99</SU>
                             
                            <E T="03">https://www.cms.gov/medicare/regulations-guidance/promoting-interoperability-programs.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>100</SU>
                             
                            <E T="03">https://www.cms.gov/regulations-and-guidance/legislation/ehrincentiveprograms#:~:text=About%20the%20Promoting%20Interoperability%20Program&amp;text=Beginning%20in%20calendar%20year%20</E>
                            (CY,for%20eligible%20hospitals%20and%20CAHs.
                        </P>
                    </FTNT>
                    <P>
                        As we have described in prior rulemakings, Congress tied the standards, implementation specifications, and certification criteria adopted as part of the Program to the incentives available under CMS Programs by requiring the meaningful use of CEHRT (75 FR 44591). Generally, we support the use of certified health IT under CMS incentive programs by establishing standards, implementation specifications, and certification criteria for health IT as part of the Program that are then incorporated into the CMS definition of CEHRT relied upon by health care providers and other users of health IT to receive incentives from CMS programs. For example, for calendar year 2023, to be considered a meaningful user and avoid a downward payment adjustment, eligible hospitals and CAHs attesting to the Medicare Promoting Interoperability Program are required to use CEHRT that has been updated to meet the 2015 Edition Cures Update certification criteria.
                        <SU>101</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>101</SU>
                             
                            <E T="03">https://www.cms.gov/Regulations-and-Guidance/Legislation/EHRIncentivePrograms/Certification#:~:text=In%20order%20to%20efficiently%20capture,data%20in%20a%20structured%20format.</E>
                        </P>
                    </FTNT>
                    <P>In the 2010 interim final rule with comment period entitled “Health Information Technology: Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology” (75 FR 2014), we first established standards and certification criteria related to public health. These included standards and certification criteria for the electronic submission of laboratory results to PHAs, electronic submission to PHAs for surveillance or reporting, and electronic submission to immunization registries. These standards and certification criteria were updated in the 2010 final rule entitled “Health Information Technology: Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology” (75 FR 44590).</P>
                    <P>In the 2012 final rule entitled “Health Information Technology: Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology, 2014 Edition; Revisions to the Permanent Certification Program for Health Information Technology” (77 FR 54163), we expanded the public health related standards and certification criteria and codified the 2014 Edition EHR certification criteria in § 170.314, with the public health certification criteria organized in § 170.314(f). The public health certification criteria in the 2012 final rule included:</P>
                    <P>• § 170.314(f)(1) “Immunization information”;</P>
                    <P>• § 170.314(f)(2) “Transmission to immunization registries”;</P>
                    <P>• § 170.314(f)(3) “Transmission to public health agencies—syndromic surveillance”;</P>
                    <P>• § 170.314(f)(4) “Inpatient setting only—transmission of reportable laboratory tests and values/results”; and,</P>
                    <P>• two “optional” certification criteria:</P>
                    <P>○ § 170.314(f)(5) “Optional—ambulatory setting only—cancer case information”; and,</P>
                    <P>○ § 170.314(f)(6) “Optional—ambulatory setting only—transmission to cancer registries.”</P>
                    <P>Then, in the 2014 final rule entitled “2014 Edition Release 2 Electronic Health Record (EHR) Certification Criteria and the ONC HIT Certification Program; Regulatory Flexibilities, Improvements, and Enhanced Health Information Exchange” (79 FR 54430), we added an optional, ambulatory-setting only certification criterion for syndromic surveillance in § 170.314(f)(7).</P>
                    <P>In the 2015 final rule entitled “2015 Edition Health Information Technology (Health IT) Certification Criteria, 2015 Edition Base Electronic Health Record (EHR) Definition, and ONC Health IT Certification Program Modifications” (2015 Edition Final Rule) (80 FR 62601), we revised the public health certification criteria to include the following:</P>
                    <P>• § 170.315(f)(1) “Transmission to immunization registries,” revised as compared to the 2014 Edition;</P>
                    <P>• § 170.315(f)(2) “Transmission to public health agencies—syndromic surveillance,” revised as compared to the 2014 Edition;</P>
                    <P>• § 170.315(f)(3) “Transmission to public health agencies—reportable laboratory tests and values/results,” revised as compared to the 2014 Edition;</P>
                    <P>• § 170.315(f)(4) “Transmission to cancer registries,” revised as compared to the 2014 Edition;</P>
                    <P>• a new certification criterion § 170.315(f)(5) “Transmission to public health agencies—electronic case reporting;”</P>
                    <P>• a new certification criterion § 170.315(f)(6) “Transmission to public health agencies—antimicrobial use and resistance reporting,” and,</P>
                    <P>• a new certification criterion § 170.315(f)(7) “Transmission to public health agencies—health care surveys.”</P>
                    <P>
                        In the in the 2020 final rule entitled “21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program” (85 FR 25642), we revised the public health certification criterion § 170.315(f)(5) “Transmission to public health agencies—electronic case reporting” to incorporate the USCDI v1 standard and C-CDA companion guide (85 FR 25671). However, in the subsequent Interim Final Rule with comment period entitled “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), we further revised that requirement so that health IT developers certifying to § 170.315(f)(5) were required to conform to data classes expressed in the USCDI standard in § 170.213 or the Common Clinical Data Set for the period before December 31, 2022 (85 FR 70076). Additionally, in a final rule titled, “Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing” (HTI-1 Final Rule) (89 FR 1192), we revised the “Transmission to public health agencies—electronic case reporting” certification criterion in § 170.315(f)(5) to replace the functional requirements 
                        <PRTPAGE P="63540"/>
                        with standards and implementation guides (IGs) and updated vocabulary standards in § 170.207(a), (c), and (e) that are referenced in several public health certification criteria.
                    </P>
                    <P>Currently, the Program includes seven certification criteria related to public health (see § 170.315(f)). We are referring to these seven certification criteria as the “(f) criteria” in this proposed rule and may refer to them in that way in future rulemaking. These (f) criteria are:</P>
                    <P>• § 170.315(f)(1) Transmission to immunization registries</P>
                    <P>• § 170.315(f)(2) Transmission to public health agencies—syndromic surveillance</P>
                    <P>• § 170.315(f)(3) Transmission to public health agencies—reportable laboratory tests and values/results</P>
                    <P>• § 170.315(f)(4) Transmission to cancer registries</P>
                    <P>• § 170.315(f)(5) Transmission to public health agencies—electronic case reporting</P>
                    <P>• § 170.315(f)(6) Transmission to public health agencies—antimicrobial use and resistance reporting</P>
                    <P>• § 170.315(f)(7) Transmission to public health agencies—healthcare surveys</P>
                    <P>Generally, the certification criteria listed above include report generation and transmission functionalities, require Health IT Modules to adhere to specific standards and implementation guides, and provide assurances that the certified Health IT Module performs as intended. However, we note that the certification criteria do not include all functionalities that may be of interest to public health, nor does the Program certify data quality or the technology that receives incoming submissions. Additionally, most of these certification criteria have not been substantially updated since 2015, as described above.</P>
                    <HD SOURCE="HD3">c. Proposal Overview</HD>
                    <P>
                        As indicated in the regulatory history, we have not updated the Program's certification criteria related to public health since 2015, with the exception of standards and IGs being added to the requirements for the “Transmission to public health agencies—electronic case reporting” certification criterion in § 170.315(f)(5) and updates to several vocabulary standards in the HTI-1 Final Rule. Standards referenced in § 170.315(f)(5), § 170.315(f)(6), and § 170.315(f)(7) have advanced through the Standards Version Advancement Process (SVAP), which allows health IT developers to voluntarily use more recent versions than those adopted in regulation as part of certification under the Program.
                        <SU>102</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>102</SU>
                             
                            <E T="03">https://www.healthit.gov/topic/standards-version-advancement-process-svap.</E>
                        </P>
                    </FTNT>
                    <P>
                        Considering the urgent need for greater public health data exchange and access to more actionable data by PHAs, we propose a multi-pronged approach that takes advantage of and builds upon the various efforts described above, including advancements in FHIR-based solutions and evolving standards related to public health interoperability. For example, a CDC report on public health data modernization found that enabling greater flow of health information from electronic health records to PHAs using HL7 FHIR-based standards could allow public health to take advantage of advanced data science capabilities such as predictive analysis, enhanced surveillance, personalized communications, and streamlining of data sharing while protecting patient privacy.
                        <SU>103</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>103</SU>
                             
                            <E T="03">https://www.cdc.gov/surveillance/data-modernization/index.html.</E>
                        </P>
                    </FTNT>
                    <P>We propose to revise the Program's current certification criteria related to public health in § 170.315(f); add several new functional requirements and adopt newer versions of standards within the current (f) criteria; add two additional certification criteria in the current (f) criteria for birth reporting and bi-directional exchange with a prescription drug monitoring program (PDMP); adopt new certification criteria for health IT for public health in § 170.315(f)(21) through (29); adopt enhancements to the standardized API for patient and population services in § 170.315(g)(10) (see section III.B.19); and adopt a new certification criterion for a standardized FHIR-based API for public health data exchange in § 170.315(g)(20), which we also propose to adopt as part of the Base EHR definition. Additionally, we propose to revise the naming of the (f) criteria to reflect first the public health use case, followed by the functionality the certification criterion supports. We believe this will help support clarity for both the use case and the specific capabilities as we continue to expand health IT supports for public health data exchange. While the proposed (f) criteria updates and additions focus primarily on health IT for public health, we believe it is likely that these certification criteria may be used in other use cases and settings.</P>
                    <P>In general, we seek to frame health IT certification criteria so that the certified health IT can be used by a wide range of entities in a different setting—including by health care providers, researchers, PHAs, or third-party entities supporting public health use cases defined in § 170.315(f), such as health information networks or other types of registries. For these public health use cases, we propose to group functions within use cases based on the implementation guides and the transactions within a bi- or multi-directional information exchange workflow. These functions may be part of a wide range of technologies, employed by a wide range of users, and we remain agnostic to the specific entity that may purchase any health IT product certified to the functionality. As such, we use the term “health IT for public health” to support the functions and transactions in the public health use cases in § 170.315(f)(21) through (29). Accordingly, we propose to revise the naming of the current (f) criteria as follows:</P>
                    <P>• § 170.315(f)(1) Immunization registries—Bi-directional exchange</P>
                    <P>• § 170.315(f)(2) Syndromic surveillance—Transmission to public health agencies</P>
                    <P>• § 170.315(f)(3) Reportable laboratory results—Transmission to public health agencies—and Laboratory Orders—Receive and validate</P>
                    <P>• § 170.315(f)(4) Cancer registry reporting—Transmission to public health agencies</P>
                    <P>• § 170.315(f)(5) Electronic case reporting—Transmission to public health agencies</P>
                    <P>• § 170.315(f)(6) Antimicrobial use and resistance reporting—Transmission to public health agencies</P>
                    <P>• § 170.315(f)(7) Health care surveys—Transmission to public health agencies</P>
                    <P>The new (f) criteria for public health data exchange and for health IT for public health that we propose to adopt are:</P>
                    <P>• § 170.315(f)(8) Birth reporting—Transmission to public health agencies</P>
                    <P>• § 170.315(f)(9) Prescription Drug Monitoring Program (PDMP) Databases—Query, receive, validate, parse, and filter</P>
                    <P>• § 170.315(f)(21) Immunization information—Receive, validate, parse, filter, and exchange—response.</P>
                    <P>• § 170.315(f)(22) Syndromic surveillance—Receive, validate, parse, and filter</P>
                    <P>• § 170.315(f)(23) Reportable laboratory test values/results—Receive, validate, parse, and filter</P>
                    <P>• § 170.315(f)(24) Cancer pathology reporting—Receive, validate, parse, and filter</P>
                    <P>
                        • § 170.315(f)(25) Electronic case reporting—Receive, validate, parse, filter, electronic initial case reports and 
                        <PRTPAGE P="63541"/>
                        reportability response; and create and transmit reportability response
                    </P>
                    <P>• § 170.315(f)(28) Birth reporting—Receive, validate, parse, and filter</P>
                    <P>• § 170.315(f)(29) Prescription Drug Monitoring Program (PDMP) Data—Receive, validate, parse, filter prescription data, support query and exchange</P>
                    <P>We also propose revisions to the “Computerized provider order entry—laboratory” certification criterion in § 170.315(a)(2) that relate to the proposed updates to the public health certification criteria listed above. Please see section III.B.18 for detail on those proposed updates to § 170.315(a)(2).</P>
                    <P>We propose this multi-pronged approach—updating existing requirements, adding new requirements for receipt, updating standards, and including a glidepath for transitioning to FHIR-based exchange in the future—to harmonize data exchange across the industry and further advance public health infrastructure to be response-ready, scalable, and flexible. We intend for this approach to allow for systems to mature and advance in an aligned fashion, reduce the need for manual workarounds and intervention, and lead to wider adoption of modern standards-based capabilities.</P>
                    <P>We understand that some health IT certification terms used in ONC's regulations for specific technical actions or capabilities may not be the same uses of the terms by the public health or healthcare sector when discussing programmatic activities. For example, in the Program we use the term “validate” in reference to the technical capability to correctly identify if a structured document or message received is conformant to a standard and if formats or vocabulary standards are valid or invalid. This is a necessary technical step to map data received in an interoperable manner. Public health or quality reporting related organizations may use the term “validate” to refer to an organizational or programmatic process to support program integrity, data accuracy, and data quality. In order to maintain consistency within the Program and to provide clarity for health IT developers, we use terms that describe health IT software functions that—while they may enable such activities by users—are specific to technical requirements. In addition, we use terms that are consistent across certification criteria—such as receive, validate, parse, and filter—to clearly and consistently define health IT functions in a manner that supports health IT developers participating in the Program. The capabilities we propose in this manner are intended to advance tools which can be used in a variety of ways to support greater efficacy across multiple programmatic and organizational use cases and processes for the public health and healthcare community.</P>
                    <P>
                        Prior experiences with the Program demonstrated an imperative to test both the sending and receiving of information, particularly in HL7 messages and documents. The initial requirement of Continuity of Care Documents (CCDs) in early iterations of the Program only included the functionality to create and send, resulting in multiple deviations and variations of the same document type and creating challenges with receiving the same standard from different vendors. Such variability included different formatting, such as line and page breaks or representation of date, as well as including or excluding specific data elements, such as onset time of problem.
                        <SU>104</SU>
                        <FTREF/>
                         These variations, while allowed under the Program at the time, made receiving, integrating, and interpreting CCDs challenging. However, when certification requirements and associated testing expectations were updated to include the receipt of CCDs as well, there was a noticeable improvement in consistency. Over time, implementation guides developed through standards development organizations became more constrained, with fewer areas of optionality, and companion guides supplemented these IGs, reducing the variations discussed above, and improving interoperability.
                    </P>
                    <FTNT>
                        <P>
                            <SU>104</SU>
                             D'Amore JD, Sittig DF, Wright A, Iyengar MS, Ness RB. The promise of the CCD: challenges and opportunity for quality improvement and population health. AMIA Annu Symp Proc. 2011; 2011:285-94. Epub 2011 Oct 22. PMID: 22195080; PMCID: PMC3243208.
                        </P>
                    </FTNT>
                    <P>These lessons in the early implementation of the Program were considered when developing the current proposals. For public health reporting, only sending systems—namely health IT used by health care providers—have been held to requirements for transmission. Similar divergence in minimum system capabilities and variable adoption and use of established national standards between certified health IT developers and health IT for public health have created challenges for PHAs, which have struggled to make use of data that is not consistent, even when it conforms to a healthcare standard. At best, these differences result in significant inefficiencies, as PHAs must develop manual workarounds and custom tools that standardize and format incoming data to reduce processing time and improve receipt, data mapping, and parsing processes. At worst, these differences impede public health's ability to quickly translate data it receives from healthcare into actions that protect and support the health of all people and their communities.</P>
                    <P>By establishing minimum functional capabilities and exchange standards for health IT and health IT for public health to send and receive public health data, we expect to enhance interoperability across healthcare and public health and provide a long-term mechanism for alignment as data exchange matures over time. Modernization efforts across health IT and health IT for public health will progress and upgrade on the same timeline, using the same standards in their entirety.</P>
                    <HD SOURCE="HD3">d. Revised Certification Criteria for Health IT Modules Supporting Public Health Data Exchange</HD>
                    <P>We propose to revise the current certification criteria located in § 170.315(f) as described below.</P>
                    <HD SOURCE="HD3">i. § 170.315(f)(1)—Immunization Registries—Bi-directional Exchange</HD>
                    <P>
                        While immunization reporting is one of the most advanced components of the public health data exchange ecosystem, challenges remain. Throughout the COVID-19 pandemic, certain issues rose in prominence, such as individuals needing access to their personal immunization histories from health IT systems and providers being unable to consistently query or view vaccines given at different places of care. Further, there were challenges with Health IT Modules being unable to consistently provide bulk access on vaccinated populations to immunization systems (
                        <E T="03">e.g.,</E>
                         to understand if students were up to date on vaccines for vaccine-preventable diseases).
                    </P>
                    <P>
                        The current certification criterion in § 170.315(f)(1) has been widely implemented in Health IT Modules but has not been updated since 2015, with the exception of the vocabulary standards in § 170.207(e) that are referenced in the certification criterion and updated in the HTI-1 Final Rule (89 FR 1226). We propose to update the Immunization Messaging Implementation Guide (IG) standard in § 170.205(e) to the HL7 v2.5.1 IG for Immunization Messaging, Release 1.5, Published October 2018, which is a compilation of the Release 1.5 version and the Addendum from 2015 referenced in the current Program, and incorporate it by reference in § 170.299. We are aware that the HL7 Public Health Workgroup will work on further updates to the IG, based in part on 
                        <PRTPAGE P="63542"/>
                        lessons learned from the pandemic, but that this new version will likely not be published until mid-to-late 2024. We welcome comments on advances beyond the current 1.5 version of the IG and encourage participation in the HL7 Public Health Workgroup. We also propose that adoption of the standard in § 170.205(e)(4) expires on January 1, 2028. Additionally, as described in the “Minimum Standards Code Sets Updates” section (III.B.5), we propose to update the vocabulary standards in § 170.207(e) that are referenced in § 170.315(f)(1) and thus are proposing to update § 170.315(f)(1)(i)(B) to reference the new proposed § 170.207(e)(5) and to update § 170.315(f)(1)(i)(C) to reference the new proposed § 170.207(e)(6).
                    </P>
                    <P>We propose to add a functional requirement in § 170.315(f)(1)(iii) to receive incoming patient-level immunization-specific query or request from external systems and respond. We propose to revise the name of the certification criterion in § 170.315(f)(1) to “Immunization registries—Bi-directional exchange” to more accurately represent the capabilities included in the certification criterion. We note that we additionally propose a requirement in support of requests for multiple patients' data as a group using an application programming interface in § 170.315(g)(20)(ii) and direct readers to section III.B.13.f for further information on that related proposal, in addition to our proposed revisions to § 170.315(g)(10) which includes capabilities to support multiple patients' data as a group using an application programming interface (section III.B.19). We expect these changes to enable more approaches for bi-directional exchange of immunization information. Further, we propose patient access to their immunization information stored in Health IT Modules using SMART Health Cards “verifiable health records” in proposed § 170.315(g)(10) and direct readers to section III.B.19 for further information on that proposal.</P>
                    <P>We expect these proposed changes would improve patient access to more complete and standardized immunization information stored in Health IT Modules, and request feedback on this approach. Specifically, we request feedback on the standard referenced in § 170.205(e) and whether we should consider adopting that soon-to-be most current version in a final rule, as we are aware that an updated version of the standard is due to be published in mid-2024. We request feedback on the functional requirement to respond to patient-level, immunization-specific queries from external systems and request comment on if the standard referenced in § 170.205(e) is sufficient for the proposed functional requirement to respond to incoming patient-level and immunization-specific queries, or if that is better handled through the IG currently going through HL7 processes for updates.</P>
                    <P>We propose to revise the certification criterion in § 170.315(f)(1) to include revised minimum standard code set requirements, updated implementation specifications, and new functionality. We propose that, for the time period up to and including December 31, 2026, a Health IT Module may continue to be certified to the existing version of the certification criterion as described in § 170.315(f)(1)(i), with proposed modifications for clarity and with a proposed revision to include the minimum standard code set updates for representation of historic and administered vaccines proposed for adoption in § 170.207(e), or it may be certified to the newly proposed certification criteria in § 170.315(f)(1)(ii) and (iii). We propose the new and revised certification criteria in § 170.315(f)(1)(ii) and (iii) to replace the existing certification criterion in § 170.315(f)(1)(i) beginning on January 1, 2027. Specifically, the proposed revisions to the certification criterion in § 170.315(f)(1)(ii) include updates to the minimum standards specified in § 170.207(e), use of newer versions of implementation specifications proposed for adoption in § 170.205(e), and new functionality to enable a user to receive and respond to incoming patient-level immunization-specific query or request from external systems. We propose that a Health IT Module certified to § 170.315(f)(1) must be updated to meet the requirements of the revised certification criterion in § 170.315(f)(1)(ii) and the requirements in § 170.315(f)(1)(iii), and that a health IT developer must provide such updated technology to their customers by no later than December 31, 2026. We propose that any Health IT Module seeking certification to the certification criterion in § 170.315(f)(1) on and after January 1, 2027, must meet the revised requirements in § 170.315(f)(1)(ii) and the requirements in § 170.315(f)(1)(iii).</P>
                    <HD SOURCE="HD3">ii. § 170.315(f)(2)—Syndromic Surveillance—Transmission to Public Health Agencies</HD>
                    <P>Syndromic surveillance has proven to be a vital component of public health data exchange and surveillance. Such data provide early indicators of public health threats, identify changes in occurrence of disease, illness, or injury patterns, and detect population-wide hazards. Today, the Program references an implementation guide last updated in 2015. Due to outdated cardinality within the standard and customization in the implementation of the standard, there are often missing or incomplete data elements.</P>
                    <P>The current certification criterion in § 170.315(f)(2) has not been updated since 2015 and references a 2015 ADT-based IG published through CDC's Public Health Information Network (PHIN). The current version of the IG, Version 2.5.1 Implementation Guide: Syndromic Surveillance, Release 1—US Realm Standard for Trial Use, July 2019 published by HL7, more specifically defines the required data elements and message specifications for an ADT-based interface implemented specifically for syndromic surveillance. This standard includes new and updated data elements to aid in public health surveillance, including, but not limited to, patient discharge disposition, patient class, diagnosis code, reason for admission, and service location. Additionally, the observation component within the implementation guide now contains additional required elements relevant to public health, including, but not limited to, pregnancy status, travel history, and acuity. These new and updated data elements provide additional information for PHAs to inform assessment of emerging threats and the proceeding action.</P>
                    <P>
                        We propose to revise the standard in § 170.205(d), which is referenced in § 170.315(f)(2), to reference the most recent IG, HL7 Version 2.5.1 Implementation Guide: Syndromic Surveillance, Release 1—US Realm Standard for Trial Use, July 2019 in § 170.205(d)(1) and incorporate it by reference in § 170.299. We also propose to add an expiration date of January 1, 2027 for the standards previously adopted in § 170.205(d)(2) and (d)(4). However, we propose that the standard adopted in § 170.205(d)(2) shall include an indication that the expiration is for the purposes of the certification criteria in § 170.315(f). We propose that the adoption of the standard in § 170.205(d)(2) on behalf of HHS shall be otherwise maintained as it is currently referenced by HHS programs for other use cases. We propose that any health IT module certified to § 170.315(f)(2) would be required to meet at least one implementation specification that is (1) adopted in § 170.205(d) or approved for SVAP and (2) not expired at the time of use. We propose that a health IT developer must update any health IT module certified to § 170.315(f)(2) and provide such 
                        <PRTPAGE P="63543"/>
                        updated module to its customers by the expiration date of the applicable standard in order to maintain certification of the health IT module. These revisions to the certification criterion in § 170.315(f)(2) would support additional data elements being shared with syndromic surveillance programs. We further propose to change the name of the criterion in § 170.315(f)(2) to Syndromic surveillance—Transmission to public health agencies.
                    </P>
                    <HD SOURCE="HD3">iii. § 170.315(f)(3)—Reportable Laboratory Results—Transmission to Public Health Agencies—and Laboratory Orders—Receive and Validate</HD>
                    <P>
                        The COVID-19 pandemic brought issues with laboratory data interoperability and associated reporting challenges to light. However, many of these issues are not specific to the pandemic and are instead due to the existing infrastructure and low adoption of current standards. Health IT Modules currently exchange older versions of the electronic laboratory reporting standard that no longer fully meet the needs of public health. We recognize there are also issues facing laboratory reporting and interoperability related to local codes and the manual effort involved with mapping local codes to standard codes. We received feedback about the challenges and time it takes for the mapping needed for exchange, and the downstream issues that occur if the mapping is not completed. However, we do not believe this can be solved solely through updates to the Program, which can require that technology support standard codes but cannot mandate that users record data using such standard codes. We will continue to partner with industry and others on addressing these broader challenges. We propose that health IT presented for certification support use of at least one of the versions of Systemized Nomenclature of Medicine—Clinical Terms (SNOMED CT®),
                        <SU>105</SU>
                        <FTREF/>
                         Logical Observation Identifiers Names and Codes (LOINC®),
                        <SU>106</SU>
                        <FTREF/>
                         and the Unified Code for Units of Measure (UCUM) 
                        <SU>107</SU>
                        <FTREF/>
                         code sets specified in § 170.207(a), (c), and (m) respectively to include updated code sets.
                    </P>
                    <FTNT>
                        <P>
                            <SU>105</SU>
                             
                            <E T="03">https://www.snomed.org/.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>106</SU>
                             
                            <E T="03">https://loinc.org/.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>107</SU>
                             
                            <E T="03">https://ucum.org/.</E>
                        </P>
                    </FTNT>
                    <P>We propose to revise the certification criterion in § 170.315(f)(3) to include these revised minimum standard code set requirements, as well as updated implementation specifications, and new functionality. The proposed revisions to the certification criterion include the same minimum standards updates in § 170.207(a), (c), and (m), use of newer versions of implementation specifications proposed for adoption in § 170.205(g), and new functionality to enable a user to receive and validate reportable laboratory order consistent with the new standards proposed for adoption in § 170.205(g).</P>
                    <P>The certification criterion in § 170.315(f)(3) is specific to lab results being transmitted to PHAs and has been applied primarily to Health IT Modules reporting laboratory values/results to jurisdictional PHAs. The certification criterion currently only includes transmission of laboratory results and does not cover functions related to the laboratory order. We propose to update the certification criterion to also include functionality for Health IT Modules to receive, validate, parse, and filter laboratory orders, according to the standard proposed in § 170.205(g)(2). We also propose to update the certification criterion to reference the standard proposed in § 170.205(g)(3) for the transmission of laboratory results.</P>
                    <P>We propose to revise the content and exchange standards for electronic transmission of lab results to PHAs in § 170.205(g). In § 170.205(g) we propose to reorganize the paragraph to include the current standard HL7 2.5.1, HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health, Release 1 (US Realm) (ELR) with Errata and Clarifications, and ELR 2.5.1 Clarification Document for EHR Technology Certification adopted in § 170.205(g) and incorporated by reference in § 170.299 into a new paragraph (1). We propose an expiration date of January 1, 2028 for the standard in § 170.205(g)(1). We propose to adopt the standard for HL7 Version 2.5.1 Implementation Guide: Laboratory Orders (LOI) from EHR, Release 1, STU Release 4—US Realm in § 170.205(g)(2) and incorporate it by reference in § 170.299. We propose to adopt in § 170.205(g)(3), and incorporate by reference in § 170.299, the standard for HL7 Version 2.5.1 Implementation Guide: Laboratory Results Interface, Release 1 STU Release 4—US Realm (LRI), and to specify the use of the Public Health Profile, in addition to the ELR IG.</P>
                    <P>We propose to revise § 170.315(f)(3)(ii) to reference LRI in addition to the HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health, Release 1 (US Realm) (ELR). We propose to revise the standards in § 170.207(a), (c), and (m), which are referenced in § 170.315(f)(3)(i) and (ii), to reference the latest versions of SNOMED CT, LOINC, and UCUM respectively. We further propose to add a functional requirement in § 170.315(f)(3)(ii) requiring the ability to receive, validate, parse, and filter reportable laboratory orders according to the standards proposed in § 170.205(g)(2) and (g)(3). Additionally, we propose to rename the certification criterion in § 170.315(f)(3) to “Reportable laboratory results—Transmission to public health agencies—and Laboratory Orders—Receive and validate.”</P>
                    <P>The proposed changes to the certification criterion in § 170.315(f)(3) would help increase the data shared between healthcare providers, laboratories, and PHAs and would increase interoperability among the different systems in place at each entity. Our proposed changes would also provide more complete patient-level information for contact tracing, patient outreach, direct care, and other clinical and public health activities.</P>
                    <P>The use of the LRI IG would provide more specificity than ELR, which can decrease the need for one-off mapping. Given the benefit of the LRI IG, we propose adding the LRI as an option for reporting to PHAs, in addition to the existing ELR IG. Additionally, the LRI and LOI IGs could have use beyond public health reporting, which can reduce implementation and maintenance burden for hospitals and providers, as both the LOI and LRI standards have multiple use cases defined in the IGs, allowing for more flexibility, reusability, and scalability. We are proposing to add the option of the public health profile in the LRI IG, given that it is an updated version of the ELR R1 IG, but request comment on whether there are additional profiles that should also be included within the LRI IG as part of the updated § 170.315(f)(3) certification criterion.</P>
                    <P>
                        The LOI IG makes important patient demographic information required, including race, ethnicity, sex, and contact information, which may allow PHAs to get more complete data in circumstances when the laboratory has these data elements and can appropriately fill the fields. This demographic information can also be used to improve patient matching, which in turn improves patient care and the efficiency of care. In one study, electronic laboratory reports were missing data on race more than one-third of the time and data on ethnicity were present less than one-fifth of the time.
                        <SU>108</SU>
                        <FTREF/>
                         Missing data in laboratory 
                        <PRTPAGE P="63544"/>
                        results to PHAs also remains a problem, which has not been solved through various attempts within industry. However, there is currently low uptake of the LOI and LRI standards, despite the increased specificity. We believe that including both standards in the Program will lead to more complete demographic information and higher rates of adoption.
                    </P>
                    <FTNT>
                        <P>
                            <SU>108</SU>
                             Electronic health information quality challenges and interventions to improve public health surveillance data and practice.—Abstract—
                            <PRTPAGE/>
                            Europe PMC. 
                            <E T="03">https://europepmc.org/article/PMC/3804098.</E>
                        </P>
                    </FTNT>
                    <P>We propose that for the time period up to and including December 31, 2027, a Health IT Module may continue to be certified to the existing version of the certification criterion as described in § 170.315(f)(3)(i), with proposed modifications for clarity and with a proposed revision to include the minimum standard code set updates in § 170.207(a), (c), and (m). We propose that a Health IT Module certified to § 170.315(f)(3) must be updated to meet the requirements of the revised certification criterion in § 170.315(f)(3)(ii) and that a health IT developer must provide such updated technology to their customers by no later than December 31, 2027. We propose that any Health IT Module seeking certification to the certification criterion in § 170.315(f)(3) on and after January 1, 2028, must meet the revised requirements in § 170.315(f)(3)(ii). We welcome comment on this proposal.</P>
                    <P>We recognize that there is a high volume of laboratory reporting interfaces in place today, for clinical and public health purposes, among others. As such, we request comment on whether the time period to phase out the ELR IG is sufficient, or if there needs to be a longer transitional period where both LRI and ELR are allowed for the purposes of transmitting laboratory results/values to PHAs. If January 1, 2028, is not feasible for the shift to only using LRI, we request comment on a feasible date for this transition.</P>
                    <P>We further request comment on whether we should specify the LOI IG standard, or whether we should instead include the functional requirements for the receipt, validation, parsing, and filtering of orders without referencing a specific standard. We also request comment on whether there are specific profiles within the LOI IG that should be referenced rather than the IG in its entirety.</P>
                    <HD SOURCE="HD3">iv. § 170.315(f)(4)—Cancer Registry Reporting—Transmission to Public Health Agencies</HD>
                    <P>Cancer reporting is an important, mandatory component of cancer control efforts in the United States. State registries collect information on diagnosed cases of cancer, treatments, and demographic information. Such information informs interventions and helps allocate resources in communities and populations affected by high rates of cancer. For example, in areas where high rates of breast cancer are diagnosed, PHAs can work with healthcare organizations and providers on programs and efforts to increase early screening and other preventative interventions.</P>
                    <P>
                        We propose to revise the certification criterion in § 170.315(f)(4) to include revised minimum standard code set requirements, updated implementation specifications, and new functionality. Since our last rulemaking cycle, there have been minor updates to the CDA Implementation Guide for Cancer Registry Reporting,
                        <SU>109</SU>
                        <FTREF/>
                         which is currently referenced in § 170.205(i)(2) and is required by the certification criterion. There is also a FHIR IG for cancer registry reporting that has been used in several pilots: Central Cancer Registry Reporting Content IG 1.0.0—STU 1.
                        <SU>110</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>109</SU>
                             
                            <E T="03">http://www.hl7.org/implement/standards/product_brief.cfm?product_id=398.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>110</SU>
                             
                            <E T="03">https://build.fhir.org/ig/HL7/fhir-central-cancer-registry-reporting-ig/usecases.html.</E>
                        </P>
                    </FTNT>
                    <P>We propose to modify the certification criterion to specify that a Health IT Module would need to support the creation and submission of cancer registry reports using either (at least one) of these standards:</P>
                    <P>• The cancer FHIR reporting bundle and accompanying profiles according to the HL7 FHIR Central Cancer Registry Reporting Content IG 1.0.0—STU1 in § 170.205(i)(3), with the requirement that all data elements indicated as “mandatory” and “must support” in the IG must be supported, including support for the requirements described in the “Central Cancer Registry Reporting HER Capability Statement,” or</P>
                    <P>• The HL7 CDA® Release 2 Implementation Guide: Reporting to Public Health Cancer Registries from Ambulatory Healthcare Providers, Release 1, DSTU Release 1.1—US Realm in § 170.205(i)(2).</P>
                    <P>Our intent would be that a certified Health IT Module supports at least one of these kinds of standards, but we do not preclude a Health IT Module from supporting both. However, we request comment on this approach and on whether we should instead require a Health IT Module certified to this certification criterion to support both the CDA IG and the FHIR reporting bundle and accompanying profiles within the Central Cancer Registry Reporting Content IG for the purpose of cancer registry reporting. We also note our proposal to create a standardized API for public health in § 170.315(g)(20) as described section III.B.13.f, which also addresses standards-based API information exchange for public health.</P>
                    <P>We also propose the inclusion of an additional requirement within the cancer registry reporting certification criterion, to include cancer pathology reporting. Cancer pathology reporting is an important component of diagnosing cancer and understanding how advanced cases are at the point of diagnosis. Pathology reporting for this certification criterion has not been part of our Program in the past, but we have heard feedback that pathology laboratory data is not being collected or exchanged in a standard way. Having standardized, electronic pathology reports would be an important foundation to more complete and accurate understanding of cancer diagnoses and assessing the stage at diagnosis. However, for cancer registries to receive all the information needed for accurate assessment, the data elements within the LRI IG are not enough for cancer pathology reporting. As such, CDC's National Program of Cancer Registries has been actively working with state PHAs and pathology partners, including the College of American Pathologists (CAP), to develop and pilot a FHIR Implementation Guide for cancer pathology reporting: Cancer Pathology Data Sharing 1.0.0—STU1. Early results of these pilots demonstrate that use of this implementation guide will reduce the need for manual intervention and data cleansing, aid in more timely reporting, and include data elements that are important for public health action.</P>
                    <P>
                        We propose to adopt the standard HL7 FHIR Cancer Pathology Data Sharing, 1.0.0—STU1 in § 170.205(i)(4) and incorporate it by reference in § 170.299. We also propose to revise § 170.315(f)(4)(ii) to add a requirement in § 170.315(f)(4)(ii)(C) to create and transmit cancer pathology laboratory values and results in accordance with the proposed standard referenced in § 170.205(i)(4), Cancer Pathology Data Sharing, 1.0.0—STU1, including support for all “mandatory” and “must support” data elements within the IG, including support for the requirements described in the “Central Cancer Registry Reporting Pathology EHR Capability Statement.” We also propose changes to the name of this certification criterion. Specifically, we propose to change the name from “Transmission to cancer registries” to “Cancer registry 
                        <PRTPAGE P="63545"/>
                        reporting—Transmission to public health agencies”. We welcome comments on the above proposal.
                    </P>
                    <P>Finally, we propose to add a timeline to allow certification of a Health IT Module to the current certification criterion in § 170.315(f)(4) for the period up to and including December 31, 2027, after which period only the revised certification criterion in § 170.315(f)(4)(ii) would be available for certification. We propose that, for the time period up to and including December 31, 2027, a Health IT Module may continue to be certified to the existing version of the certification criterion as described in § 170.315(f)(4)(i), with modifications for clarity and with a proposed revision to include the minimum standard code set updates. The proposed revisions to the certification criterion include updates to the same minimum standards updates, use of newer versions of implementation specifications, and new functionality as described above. We propose that a Health IT Module certified to § 170.315(f)(4) must be updated to meet the requirements of the revised certification criterion and that a health IT developer must provide such updated technology to their customers by no later than December 31, 2027. We propose that a Health IT Module seeking certification to § 170.315(f)(4) on and after January 1, 2028, must meet the requirements described in § 170.315(f)(4)(ii).</P>
                    <P>We welcome comments on the above proposal.</P>
                    <HD SOURCE="HD3">v. § 170.315(f)(5) Electronic Case Reporting—Transmission to Public Health Agencies</HD>
                    <P>In the HTI-1 Final Rule, we finalized requirements in § 170.315(f)(5) for compliance with specific standards for electronic case reporting to PHAs (89 FR 1231). Based on commenters' response to the proposal, we finalized allowing either the CDA or FHIR standard for the transmission of electronic case reports and reportability responses (RRs), as well as the ability to consume and process electronic case reporting trigger codes based on a match from the Reportable Conditions Trigger Code (RCTC) value set as specified in the HL7 FHIR electronic case reporting (eCR) IG. As finalized in the HTI-1 Final Rule, after December 31, 2025, developers would only be able to certify to case reporting using the standards-based approach described § 170.315(f)(5)(ii), and previously certified products would need to update their certification to the standards-based approach described in § 170.315(f)(5)(ii) by December 31, 2025 (89 FR 1228).</P>
                    <P>We believe requiring Health IT Modules to conform to a single standard, specifically the HL7 FHIR standard, would coalesce industry, PHAs, and other interested parties to dedicate resources towards improved functionality and interoperability for electronic case reporting. The use of HL7 FHIR-based solutions encourages more flexibility and reduced burden for both initial development as well as maintenance for healthcare information technology developers and aligns with CDC's Public Health Data Strategy. The Public Health Data Strategy prioritizes electronic case reporting as an important automation that reduces burden and encourages more complete and timely data exchange.</P>
                    <P>We propose no changes to the capabilities specified within the certification criterion in § 170.315(f)(5), but we do propose to update the standard used for the certification criterion in § 170.205(t)(2). Given the potential benefits of adopting a single standard, and our overall progress toward shifting to HL7 FHIR-based standards and solutions when appropriate and feasible, we propose that adoption of the CDA-based standard in § 170.205(t)(2) expires on January 1, 2028. This proposal would have the effect of requiring all Health IT Modules certified to § 170.315(f)(5) to use the eICR profile of the HL7 FHIR eCR IG in § 170.205(t)(1). We propose that Health IT Modules be required to support the HL7 FHIR-based IGs beginning January 1, 2028 to allow developers, intermediaries, and PHAs to make the needed updates to the HL7 FHIR eCR IG and develop needed system upgrades and solutions to transmit electronic case reports and receive RRs that adhere to the HL7 FHIR eCR IG implementation specification adopted in § 170.205(t)(1).</P>
                    <P>We propose to maintain in § 170.315(f)(5)(ii) adherence to specific aspects of the HL7 FHIR eCR IG to allow for flexibility: the electronic initial case report (eICR) profiles and the RR profile of the HL7 FHIR eCR IG, and the ability to consume and process electronic case reporting trigger codes and identify a reportable patient visit or encounter based on a match from the Reportable Conditions Trigger Code value set as specified in the HL7 FHIR eCR IG. We welcome comments on this proposal.</P>
                    <HD SOURCE="HD3">vi. § 170.315(f)(6)—Antimicrobial Use and Resistance Reporting—Transmission to Public Health Agencies</HD>
                    <P>
                        The monitoring of antimicrobial use and resistance is a vital component of public health reporting, particularly as antimicrobial resistance rates continue to rise across the United States.
                        <SU>111</SU>
                        <FTREF/>
                         In order to adequately address this issue, timely reporting to PHAs is important; such reporting can allow for prescribers to receive feedback regarding prescribing practices and improve the appropriate use of antimicrobials.
                    </P>
                    <FTNT>
                        <P>
                            <SU>111</SU>
                             
                            <E T="03">https://www.cdc.gov/nhsn/pdfs/pscmanual/11pscaurcurrent.pdf.</E>
                        </P>
                    </FTNT>
                    <P>CDC's National Healthcare Safety Network (NHSN) collects information on antimicrobial use and resistance from inpatient facilities enrolled in and reporting to its Patient Safety Component, including (but not limited to) general hospitals, CAHs (critical access hospitals), children's hospitals, long term acute care hospitals, military and veterans' hospitals, psychiatric hospitals, and rehabilitation hospitals. CDC uses antimicrobial use and resistance data reported through NHSN to generate metrics that states, facilities, and other users, such as hospital associations, use to improve clinical care and guide public health action. These data also provide a national picture of the threat posed by antimicrobial overuse and resistance. Given the importance of these data for patient safety and national efforts to combat antibiotic resistance, in FY 2022, CMS finalized a requirement that eligible hospitals and CAHs participating in the Medicare Promoting Interoperability Program must begin reporting a new Antimicrobial Use and Resistance (AUR) Surveillance measure for Electronic Health Record (EHR) reporting periods in calendar year (CY) 2024 (87 FR 49335 through 49337).</P>
                    <P>
                        We propose minimal changes to the certification criterion in § 170.315(f)(6), specifically, revising to reference the standard in § 170.205(r) instead of the current reference to § 170.205(r)(1). We then propose several revisions to the standard adopted in § 170.205(r). Specifically, we propose the adoption of the standard in § 170.205(r)(1) would expire on January 1, 2027. We also propose that the standard in § 170.205(r)(1) only requires conformance to § 170.205(r)(1)(i) and (ii) for the time period up to and including December 31, 2025. We propose to add an updated version of the standard in § 170.205(r)(2) to include HL7 CDA® R2 Implementation Guide: Healthcare Associated Infection (HAI) Reports, Release 3—US Realm, December 2020 and to incorporate it by reference in § 170.299. The updated IG can lead to more specific and complete information being shared with PHAs, allowing for follow-up activities and research to address rising rates of antimicrobial resistance. The updated version 
                        <PRTPAGE P="63546"/>
                        includes new and updated templates and value sets that enable more advanced reports. This proposal would mean that the updated templates in the new IG would replace the two specific components of the prior IG in § 170.205(r)(1) identified for expiration on January 1, 2026, and then upon the expiration of the prior standard in its entirety on January 1, 2027, the updated template in the new IG in § 170.205(r)(2) would become the only applicable version of the specifications for certification to the certification criterion.
                    </P>
                    <P>This updated version of the standard was previously advanced for voluntary adoption under our SVAP process for two of the three sections required within the current certification criteria: HAI Antimicrobial Use and Resistance (AUR) Antimicrobial Resistance Option (ARO) Report (Numerator) specific document template in Section 2.1.2.1 and Antimicrobial Resistance Option (ARO) Summary Report (Denominator) specific document template in Section 2.1.1.1. We propose advancing to the updated version by expiring the adoption of the prior standard components on January 1, 2026, for two of the required sections of the implementation guide referenced within current certification criteria given benefits listed above and advancement of system capabilities to support the standard since previous SVAP cycles. The third required component, “Antimicrobial Use (AUP) Summary Report (numerator and denominator)” should continue to use the standard HL7 Implementation Guide for CDA Release 2—Level 3: Healthcare Associated Infection Reports, Release 1, U.S. Realm, until the expiration date of the entire standard on January 1, 2027. The two required components that are in the updated IG are HAI Antimicrobial Use and Resistance (AUR) Antimicrobial Resistance Option (ARO) Report (Numerator); Antimicrobial Resistance Option (ARO) Summary Report (Denominator).</P>
                    <P>We also propose minimal changes to the name of the certification criterion in § 170.315(f)(6) to be “Antimicrobial use and resistance reporting—Transmission to public health agencies.” We welcome comments on the above proposal.</P>
                    <HD SOURCE="HD3">vii. § 170.315(f)(7)—Health Care Surveys—Transmission to Public Health Agencies</HD>
                    <P>
                        Data from the National Health Care Surveys, sent to CDC's National Center for Health Statistics, provides information on healthcare utilization, and includes information related to symptoms, diagnoses, and procedures. These surveys are nationally representative, provider-based, and cover a broad spectrum of healthcare settings. Within each setting, data are collected from a sample of organizations that provide care and from samples of patient (or discharge) encounters within the sampled organizations. Data are collected not only from traditional healthcare settings such as hospitals and physicians' offices, but also from long-term care providers and community health centers. These surveys help provide insight to inform policy, research, and quality; sending them electronically allows for wider representation from hospitals and healthcare organizations, as well as reduces manual burden on the reporters.
                        <SU>112</SU>
                        <FTREF/>
                         Improving the process for electronic collection of survey data, including the use of standards, could make these important surveys easier to administer.
                    </P>
                    <FTNT>
                        <P>
                            <SU>112</SU>
                             
                            <E T="03">https://www.cdc.gov/nchs/dhcs/index.htm?CDC_AA_refVal=https%3A%2F%2Fwww.cdc.gov%2Fnchs%2Fdhcs.htm.</E>
                        </P>
                    </FTNT>
                    <P>We propose minimal changes to the certification criterion in § 170.315(f)(7), specifically, revising to reference the standard in § 170.205(s) instead of the current reference to § 170.205(s)(1). We then propose to add an expiration date of January 1, 2027, to the standard for healthcare survey information for electronic transmission specified in § 170.205(s)(1). We also propose to revise § 170.205(s)(2), which is currently reserved, to reference HL7 CDA R2 Implementation Guide: National Health Care Surveys (NHCS), R1 STU Release 3.1—US Realm and incorporate it by reference in § 170.299. To advance the electronic transmission of healthcare surveys and include the relevant and needed information to achieve its intent, we propose this version of the standard, as it includes new and updated templates with important context. These revisions include, but are not limited to, changes to sections for emergency department encounters, patient information sections, gender identity observation, and number of visits over the past 12 months. Such information will provide additional insight on trends in hospitalization, surveillance of symptomology and diagnoses, and demographics that can highlight disparities and better inform interventions.</P>
                    <P>We are aware that the HL7 FHIR Health Care Surveys Content Implementation Guide has gone through the HL7 approval process and was published in 2023. We are further aware that a FHIR pilot project for using FHIR standards to send survey information was initiated in fall of 2023. We have not proposed to include this newer, FHIR-based standard for healthcare survey information at this time, but request feedback on whether it should be an option for health care surveys. Specifically, we request comment on whether we should consider modifying the certification criterion to require a Health IT Module certified to this criterion to support creation and submission using at least one of these standards:</P>
                    <P>• The HL7 FHIR Health Care Surveys Content IG; or,</P>
                    <P>• The HL7 CDA R2 Implementation Guide: National Health Care Surveys (NHCS), R1 STU Release 3.1—US Realm.</P>
                    <P>Under this alternative, a Health IT Module certified to this criterion would be required to support at least one of these kinds of standards but would not be precluded from supporting both. We welcome comment on this proposal—in particular, on current usability and maturity of the FHIR IG and readiness among certified health IT vendors to implement it.</P>
                    <P>We also propose minimal changes to the name of this certification criterion in § 170.315(f)(7) to be “health care surveys—transmission to public health agencies.” We welcome comment on this proposal, including on FHIR-based approaches.</P>
                    <HD SOURCE="HD3">e. New Certification Criteria for Health IT Modules Supporting Public Health Data Exchange</HD>
                    <P>We propose to establish new certification criteria as described below for Health IT Modules supporting public health data exchange. These certification criteria would certify the ability of Health IT Modules to receive HL7 v2, CDA-based, and/or FHIR reports for birth reporting and Prescription Drug Monitoring Programs (PDMPs). Additionally, certification criteria proposed in this section would certify receive, validate, parse, and filter capabilities related to immunization information, syndromic surveillance, cancer pathology reports, electronic case reporting, birth reporting, and PDMP data.</P>
                    <HD SOURCE="HD3">i. § 170.315(f)(8)—Birth Reporting—Transmission to Public Health Agencies</HD>
                    <P>
                        Providers currently rely on manual and duplicative data entry processes to report information on live births to state vital records offices. With most U.S. births occurring in hospitals or free-standing birthing facilities, birth reporting typically entails clinicians supplying the medical and health information for the birth certificate to a 
                        <PRTPAGE P="63547"/>
                        state web-based Electronic Birth Registration System (EBRS) or nonclinical hospital staff reviewing the hospital medical records for the information and entering it into the state EBRS. The legal and demographic information is typically collected directly from the mother using a standardized worksheet, and the information is then entered into the State EBRS by nonclinical hospital staff. This information is then sent to the state and a birth certificate is then issued by the state vital records authority. Much of the medical and health information collected for the birth certificate necessary to report a live birth is also dually entered into EHRs by health care providers. As a result, birth reporting processes are duplicative and burdensome for providers and hospital systems.
                    </P>
                    <P>Low adoption of standards to exchange data between EHRs and EBRSs have resulted in an overall lack of interoperability between all systems involved in birth reporting processes. CDC has provided significant funding and resources to support the adoption of EBRSs by PHAs and providers. Recent funding has also been provided to PHAs to develop and advance the use of the FHIR standard to report information. Despite investments made by CDC towards standards-based exchange with EBRSs, there has been very little uptake of these standards and associated functionalities by health IT developers.</P>
                    <P>
                        We propose to adopt a new certification criterion, “Birth reporting—Transmission to public health agencies.” As a part of this new certification criterion, we propose to adopt the HL7 FHIR Vital Records Birth and Fetal Death Reporting-1.1.0—STU 1.1 in § 170.205(v) for electronically submitting medical and health information from birth certificate reports to PHAs.
                        <SU>113</SU>
                        <FTREF/>
                         However, if an updated version of this IG is published prior to the publication of a final rule, and made available to the public, it would be our intent to consider adopting the updated IG if it best aligns with and supports effective implementation of this proposed certification criterion. Based on public comments on HTI-1 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 89 FR 1215). We encourage commenters to comment on the preferred version associated with this proposal.
                    </P>
                    <FTNT>
                        <P>
                            <SU>113</SU>
                             Please 
                            <E T="03">see https://hl7.org/fhir/us/bfdr/2024Jan/.</E>
                        </P>
                    </FTNT>
                    <P>
                        Additionally, we request comment specifically on whether the content specified in the IG can be exchanged using transport mechanisms defined in § 170.315(g)(10) and in the proposed § 170.315(g)(20) certification criteria. The selected information included in the standard in § 170.205(v) was piloted by the Michigan Health and Human Services Division for Vital Records and Health Statistics with four Michigan hospitals and their EHRs. In Michigan, the pilot has found increased data completion and accuracy for many data items when births are reported using the FHIR standard and a SMART-on-FHIR app when compared to reports completed manually by hospital staff.
                        <SU>114</SU>
                        <FTREF/>
                         We believe the standard, when adopted broadly, could aid in timely, more complete, and accurate reporting from hospitals with reduced burden on the reporting facilities. We seek comment from those who have implemented and used the IG on its readiness for nationwide adoption.
                    </P>
                    <FTNT>
                        <P>
                            <SU>114</SU>
                             Final Report submitted to Centers for Disease Control and Prevention In response to Request for Task Order Proposal No. (MI 2020-Q-45799), June 16, 2023.
                        </P>
                    </FTNT>
                    <P>
                        As an alternative to the IG proposed above, we propose, and seek comment on, adoption of an interim standards-agnostic functional criterion for electronically transmitting medical and health information from birth certificate reports to PHAs based on the data elements outlined in CDC National Vital Statistics System's “Guide to Completing the Facility Worksheets for the Certificate of a Live Birth and Report of Fetal Death.” 
                        <SU>115</SU>
                        <FTREF/>
                         We further seek comment on the potential benefits and risks of adopting a functional approach, particularly as CDC's NCHS has retired and will not be actively updating the HL7 Version 2.6 Implementation Guide: Vital Records Birth and Fetal Death Reporting, Release 1 STU Release 2 and the HL7 CDA R2 Implementation Guide: Birth and Fetal Death Reporting, Release 1, STU Release 2—U.S. Realm standards. Finally, we request comment on whether a functional approach—if adopted—should be time-limited and require a transition to a standards-based approach as of a specific timeline. For example, a functional approach could be permitted for certification up to and including December 31, 2026, and then the standards-based approach for conformance would be required thereafter.
                    </P>
                    <FTNT>
                        <P>
                            <SU>115</SU>
                             
                            <E T="03">https://www.cdc.gov/nchs/nvss/facility-worksheets-guide.htm.</E>
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">ii. § 170.315(f)(9)—Prescription Drug Monitoring Program (PDMP) Databases—Query, Receive, Validate, Parse, and Filter</HD>
                    <P>We propose to adopt a new certification criterion to enable the bi-directional interaction and electronic data exchange between Health IT Modules and PDMP databases (referred to hereafter as PDMPs). Specifically, we propose a certification criterion to enable the query of prescription drug monitoring systems and the receipt, validation, parsing, and filtering of medication information from PDMPs. This aligns with a current requirement in CMS' Medicare Promoting Interoperability Program where Query of PDMP is a required measure.</P>
                    <HD SOURCE="HD3">PDMP Background</HD>
                    <P>
                        ONC has engaged in collaborative work to understand health IT's role in addressing the opioid crisis, including the opportunities created by state-run health IT systems known as PDMPs.
                        <SU>116</SU>
                        <FTREF/>
                         PDMPs are state-run electronic databases that provide critical health information to physicians and other health care providers about an individual's history of controlled substance prescriptions (and, in some states, more complete histories of all prescriptions). Evaluations of PDMPs suggest their use supports changes in prescribing behaviors, reduces use of multiple providers by patients, and decreases treatment admissions associated with substance misuse.
                        <SU>117</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>116</SU>
                             
                            <E T="03">See</E>
                             for reference: 
                            <E T="03">https://www.healthit.gov/sites/default/files/page/2023-03/LPASO_Landscape_Assessment_508.pdf.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>117</SU>
                             
                            <E T="03">See</E>
                             for reference: 
                            <E T="03">https://www.cdc.gov/drugoverdose/pdmp/index.html.</E>
                        </P>
                    </FTNT>
                    <P>
                        Beginning in 2012, ONC, in collaboration with the Substance Abuse and Mental Health Services Administration (SAMHSA), sought to identify ways to use health IT to improve access to PDMPs. The collaborative project resulted in the development of the “Enhancing Access to Prescription Drug Monitoring Programs Using Health Information Technology: Work Group Recommendations Report,” 
                        <SU>118</SU>
                        <FTREF/>
                         and 13 pilot studies to test the feasibility of connecting PDMPs with health IT systems.
                        <SU>119</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>118</SU>
                             Enhancing Access to Prescription Drug Monitoring Programs Using Health Information Technology. (2012). 
                            <E T="03">https://www.healthit.gov/sites/default/files/work_group_document_integrated_paper_final_0.pdf; see also https://www.cdc.gov/drugoverdose/pdf/pehriie_report-a.pdf.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>119</SU>
                             
                            <E T="03">https://www.healthit.gov/topic/health-it-health-care-settings/enhancing-access-pilot-reports.</E>
                        </P>
                    </FTNT>
                    <P>
                        Bipartisan legislation aimed to address the opioid crisis—the 21st Century Cures Act (Cures Act) of 2016 
                        <PRTPAGE P="63548"/>
                        (Pub. L. 114-255),
                        <SU>120</SU>
                        <FTREF/>
                         and the Substance Use Disorder Prevention that Promotes Opioid Recovery and Treatment for Patients and Communities Act (SUPPORT Act) of 2018 (Pub. L. 115-271).
                        <SU>121</SU>
                        <FTREF/>
                         Additionally, the Commission on Combating Drug Addiction and the Opioid Crisis (Commission) was established in 2017 
                        <SU>122</SU>
                        <FTREF/>
                         to develop recommendations to address the opioid epidemic. In November 2017, the Commission released a final report with recommendations focused on reducing barriers and supporting programs and innovations aimed at strengthening Federal, state, and local responses to the opioid overdose epidemic.
                        <SU>123</SU>
                        <FTREF/>
                         Several of the report's recommendations include the use of state-run programs and health IT to address substance use disorder (SUD) and opioid use disorder (OUD).
                    </P>
                    <FTNT>
                        <P>
                            <SU>120</SU>
                             21st Century Cures Act. (2016). 
                            <E T="03">https://www.gov info.gov/content/pkg/PLAW-114publ255/pdf/PLAW-114publ255.pdf.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>121</SU>
                             Substance Use-Disorder Prevention that Promotes Opioid Recovery and Treatment for Patients and Communities Act. (2018). 
                            <E T="03">https://www.congress.gov/bill/115th-congress/house-bill/6/text.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>122</SU>
                             The White House. (2017). 
                            <E T="03">https://trumpwhitehouse.archives.gov/presidential-actions/president-donald-j-trump-signs-executive-order-establishing-presidents-commission-combating-drug-addiction-opioid-crisis/.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>123</SU>
                             The Commission on Combating Drug Addiction and the Opioid Crisis. (2017). 
                            <E T="03">https://www.whitehouse.gov/sites/whitehouse.gov/files/images/Final_Report_Draft_11-15-2017.pdf.</E>
                        </P>
                    </FTNT>
                    <P>
                        These laws included important provisions related to PDMPs, health IT supports for OUD, and the integration of health IT supports into clinical workflows for OUD prevention and treatment. Section 1944(b) of the Social Security Act, as added by Section 5042(a) of the SUPPORT Act, also requires that states implement a qualified PDMP and defines the requirements for a qualified PDMP including that the PDMP administered by the state, at a minimum: 
                        <SU>124</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>124</SU>
                             Section 1944(b) of the Social Security Act [42 U.S.C. 1396w-3a] as added by section 5042(a) of the Substance Use Disorder Prevention that Promotes Opioid Recovery and Treatment for Patients and Communities Act (SUPPORT Act) of 2018 (Pub. L. 115-271).
                        </P>
                    </FTNT>
                    <P>• Facilitates access by a covered provider with respect to a covered individual—in as close to real time as possible—of patient-specific information for prescription drug history with regard to controlled substances, the number and type of controlled substances prescribed and filled in at least the most recent 12-month period, and information relating to each covered provider of such medications; and</P>
                    <P>• Facilitates the integration of the information into the workflow of a covered provider, which may include the electronic system the covered provider uses to prescribe controlled substances.</P>
                    <P>
                        In addition, Section 1944(a) of the Social Security Act, as added by Section 5042(a) of the SUPPORT Act, directs states to implement requirements that certain covered Medicaid Providers check the qualified PDMP for Medicaid beneficiaries' prescription information prior to prescribing applicable controlled substances.
                        <SU>125</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>125</SU>
                             Section 1944(a) of the Social Security Act [42 U.S.C. 1396w-3a] as added by section 5042(a) of the SUPPORT Act of 2018 (Pub. L. 115-271). 
                            <E T="03">See also https://www.medicaid.gov/federal-policy-guidance/downloads/faq051519.pdf.</E>
                        </P>
                    </FTNT>
                    <P>
                        The establishment and operation of PDMPs vary given that each PDMP is subject to existing policies and management of their own respective state. While PDMPs may operate differently, there are system components guidance that CDC promotes to improve PDMP functionality as a public health tool.
                        <SU>126</SU>
                        <FTREF/>
                         Those include:
                    </P>
                    <FTNT>
                        <P>
                            <SU>126</SU>
                             CDC Clinical Practice Guidelines for Prescribing Opioids (Dowell D, Ragan KR, Jones CM, Baldwin GT, Chou R. CDC Clinical Practice Guideline for Prescribing Opioids for Pain—United States, 2022. MMWR Recomm Rep 2022;71(No. RR-3):1-95. DOI:
                            <E T="03">http://dx.doi.org/10.15585/mmwr.rr7103a1</E>
                            ).
                        </P>
                    </FTNT>
                    <P>• Universal use among clinicians and/or their delegates (for example, nurse practitioners or physician assistants) within a state;</P>
                    <P>• More timely or real-time data contained within a PDMP;</P>
                    <P>• Actively managing the PDMP in part by sending proactive reports to clinicians to inform prescribing; and</P>
                    <P>• Ensuring that PDMPs are easy to use and accessible by clinicians.</P>
                    <P>
                        As of the publication of this proposed rule, 50 states, the District of Columbia, and three territories have established PDMPs, each with various requirements for querying and reporting from pharmacy information systems. Of these 54 PDMPs, 51 have additionally implemented regulations mandating the use of the state PDMP when prescribing controlled substances, sometimes for new patients or other scenarios.
                        <SU>127</SU>
                        <FTREF/>
                         However, despite the increase in PDMP utilization and promising, though mixed, evidence of their effectiveness, PDMPs are only able to truly impact care if prescribers and pharmacists use them, and when PDMP data are easily accessible in clinical workflows and accessible across state lines. While requirements are in place for providers to access PDMPs at the state level, states generally do not have specific requirements for PDMPs to support direct queries—in practice this leads to indirect query workflows and multiple translation points, creating gaps in interoperability. Additionally, there are no widespread established practices for integrating query information into clinical workflows within health IT systems—despite recommendations from CDC that, when prescribing initial opioid therapy for acute, subacute, or chronic pain, clinicians should review a patient's history of controlled substance prescriptions as well as non-opioid therapies using state PDMP data.
                        <SU>128</SU>
                        <FTREF/>
                         In addition, health IT systems may lack sufficient capabilities to reconcile query data from PDMP systems as discrete data element(s). At the same time, PDMPs also need to be able to respond to a query from a certified Health IT Module with discrete data.
                    </P>
                    <FTNT>
                        <P>
                            <SU>127</SU>
                             
                            <E T="03">https://www.medicaid.gov/medicaid/data-and-systems/downloads/rtc-5042-state-challenges.pdf.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>128</SU>
                             CDC Clinical Practice Guideline for Prescribing Opioids for Pain—United States, 2022 | MMWR.
                        </P>
                    </FTNT>
                    <P>
                        Today, authorized users may have to access PDMP data that is not integrated into their workflow, as it is accessed through a separate portal, which may add to clinical burden and decrease the likelihood of checking and utilizing the PDMP data.
                        <SU>129</SU>
                        <FTREF/>
                         These pieces—integrating query information into health IT systems and informing workflow integration practices based on established guidelines, along with reconciling query data as discrete data elements for both the PDMP and certified Health IT Module—are supported by the functions we propose below.
                    </P>
                    <FTNT>
                        <P>
                            <SU>129</SU>
                             
                            <E T="03">https://www.healthit.gov/sites/default/files/page/2023-03/LPASO_Landscape_Assessment_508.pdf.</E>
                        </P>
                    </FTNT>
                    <P>
                        From 2018 to 2022, ONC and CDC collaborated on the Advancing PDMP and EHR Integration project. The purpose of this project was to advance and scale vendor agnostic PDMP integrations with health IT systems in a variety of hospital, primary care, and outpatient settings. This effort produced an Integration Framework and Integration Toolkit to serve as technical resources for organizations interested in integrating PDMP with a variety of health IT systems.
                        <SU>130</SU>
                        <FTREF/>
                         The Integration Framework includes how best to implement advanced technologies such as electronic CDS systems that clinicians are increasingly using to combat the opioid crisis as well as information to help improve integration of state PDMPs within clinicians' workflows. The Integration Framework 
                        <PRTPAGE P="63549"/>
                        also includes helpful resources, such as MOU, auditing, and testing guidance, which can help advance and scale PDMP integration with health IT systems (
                        <E T="03">e.g.,</E>
                         EHR systems, health information exchanges, and pharmacy systems) in a variety of hospital, primary care, and outpatient settings.
                        <SU>131</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>130</SU>
                             HHS ONC/CDC Health Information Technology: Integration Framework for PDMP-EHR Integration: June, 2021: 
                            <E T="03">https://www.cdc.gov/opioids/pdf/Integration-Framework.pdf.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>131</SU>
                             “Using Health IT Integration to Address the Drug Overdose Crisis” August 2022: 
                            <E T="03">https://www.healthit.gov/buzz-blog/electronic-health-and-medical-records/using-health-it-integration-to-address-the-drug-overdose-crisis.</E>
                        </P>
                    </FTNT>
                    <P>
                        In 2018, CMS issued frequently asked questions outlining how a state could ensure that its qualified PDMP aligns with and incorporates industry standards, consistent with 42 CFR 433.112(b)(12), and encouraged states to refer to the information on standards in the Interoperability Standards Advisory (ISA) published by the ONC, specifically the section of the ISA describing, “A Prescriber's Ability to Obtain a Patient's Medication History from a Prescription Drug Monitoring Program,” which outlined recommended industry standards for PDMP and EHR integration informed by the efforts of ONC and CDC to advance PDMP best practices.
                        <SU>132</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>132</SU>
                             
                            <E T="03">https://www.medicaid.gov/federal-policy-guidance/downloads/faq051519.pdf.</E>
                        </P>
                    </FTNT>
                    <P>
                        The 2022 CDC Clinical Practice Guideline for Prescribing Opioids for Pain 
                        <SU>133</SU>
                        <FTREF/>
                         (2022 Clinical Practice Guideline) includes information that updates and replaces the 2016 CDC Guideline for Prescribing Opioids for Chronic Pain. The 2022 Clinical Practice Guideline provides evidence-based recommendations for prescribing opioid pain medication for acute, subacute, and chronic pain for outpatients aged 18 years or older, excluding pain management related to sickle cell disease, cancer-related pain treatment, palliative care, and end-of-life care. The 2022 Clinical Practice Guideline takes into account new science and data, along with lessons learned about the challenges faced by patients managing pain and pain care. The 2022 Clinical Practice Guideline also includes a key update that specifies which recommendations apply to patients who are being considered for 
                        <E T="03">initial</E>
                         treatment with prescription opioids versus those that have 
                        <E T="03">already been receiving</E>
                         opioids as part of ongoing care.
                    </P>
                    <FTNT>
                        <P>
                            <SU>133</SU>
                             CDC Clinical Practice Guideline for Prescribing Opioids for Pain—United States, 2022 
                            <E T="03">https://www.cdc.gov/mmwr/volumes/71/rr/rr7103a1.htm.</E>
                        </P>
                    </FTNT>
                    <P>
                        In March of 2023, ONC published a report from the 
                        <E T="03">Leveraging PDMPs and Health IT for Addressing SUD/OUD (LPASO)</E>
                         Project landscape assessment. The LPASO Project was originally established in 2018 to examine how jurisdictions utilize PDMPs and health IT to support SUD/OUD identification, prevention, and treatment. Specifically, ONC was interested in identifying and describing the policy and technical approaches to addressing the opioid overdose epidemic related to PDMPs for several key characteristics termed “indicators” (bolded for emphasis).
                        <SU>134</SU>
                        <FTREF/>
                         The PDMP indicators included in this analysis were:
                    </P>
                    <FTNT>
                        <P>
                            <SU>134</SU>
                             Leveraging Prescription Drug Monitoring Programs and Health Information Technology for Addressing Substance Use Disorder and Opioid Use Disorder: A Landscape Assessment of Prescription Drug Monitoring Programs and Health Information Technology Indicators—March 2023: 
                            <E T="03">https://www.healthit.gov/sites/default/files/page/2023-03/LPASO_Landscape_Assessment_508.pdf.</E>
                        </P>
                    </FTNT>
                    <P>
                        • 
                        <E T="03">PDMP data placement in health IT systems:</E>
                         State statutes and policies that allow PDMP data to be stored in another system such as the EHR (
                        <E T="03">e.g.,</E>
                         included in provider notes, medication history, etc.) as compared to a one-time view of the PDMP data.
                    </P>
                    <P>
                        • 
                        <E T="03">Interpretation of PDMP data:</E>
                         State statutes and policies related to the use of PDMP data for predictive analytics such as risk scores.
                    </P>
                    <P>
                        • 
                        <E T="03">PDMP access roles:</E>
                         Categories of professionals who are authorized by state statute or other policies to access PDMP data.
                    </P>
                    <P>
                        • 
                        <E T="03">PDMP hospital integration:</E>
                         Prevalence of PDMP integration within the clinical workflow. This indicator examined whether hospitals provided access to the PDMP within the hospital's EHR system or outside of the hospital's EHR system via a PDMP portal or secure website.
                    </P>
                    <P>
                        • 
                        <E T="03">Data standards and hubs used for PDMP data capture, exchange, and reporting:</E>
                         Health IT components and data standards in use for the transport, interpretation, and integration of PDMP data including those used for interstate data sharing.
                    </P>
                    <P>
                        The LPASO report presented the findings of the landscape analysis for each of these indicators, which is summarized below. The LPASO Project identified that where state law permitted the care team access to the PDMP data within a medical record and to incorporate the data as a discrete data element—as opposed to view only access—clinicians are better able to coordinate care, to assess prescribing practices across the organization, and to implement OUD prevention and treatment best practices.
                        <SU>135</SU>
                        <FTREF/>
                         Further, the LPASO Project found that clinical decision support tools can help clinicians across a wide range of specialties to better identify at-risk patients and facilitate best practices for OUD prevention and treatment. However, some clinicians have expressed concern at the potential risk of such analytics tools including variations in threshold values, lack of transparency for algorithms, and the potential for scores to over-simplify risk that could be identified with a more detailed review of PDMP data.
                        <SU>136</SU>
                        <FTREF/>
                         The LPASO report also found that the content received in response to a PDMP query varied in terms of clinical usefulness and, after querying, receiving a risk score based on a proprietary algorithm was of limited utility and inconsistently predictive of negative outcomes.
                        <SU>137</SU>
                        <FTREF/>
                         Additionally, state laws and regulations determine the categories of users who are authorized to access and use a state's PDMP data, and there is considerable variability in the number and types of access roles identified in each state. A 2018 analysis of the PDMP Training and Technical Assistance Center's (TTAC) data revealed that there are 63 unique access roles identified across all states and jurisdictions. This analysis indicated:
                    </P>
                    <FTNT>
                        <P>
                            <SU>135</SU>
                             
                            <E T="03">Ibid.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>136</SU>
                             Call for better validation of opioid overdose risk algorithms | Journal of the American Medical Informatics Association | Oxford Academic (
                            <E T="03">oup.com</E>
                            ).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>137</SU>
                             
                            <E T="03">https://pubmed.ncbi.nlm.nih.gov/31356498/.</E>
                        </P>
                    </FTNT>
                    <P>• In all states and jurisdictions, prescribers and pharmacists are allowed access to the PDMP.</P>
                    <P>• A majority of states and jurisdictions (more than 50) also allow access for law enforcement, physician assistants, nurse practitioners, and prescriber delegates.</P>
                    <P>
                        • A majority of states and jurisdictions (more than 40) also include an access role for “patient.” 
                        <SU>138</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>138</SU>
                             Prescription Drug Monitoring Program Training and Technical Assistance Center. (2018). 
                            <E T="03">http://www.pdmpassist.org/content/state-profiles.</E>
                        </P>
                    </FTNT>
                    <P>
                        The Prescription Monitoring Information Exchange (PMIX) Healthcare Roles document was developed by the PDMP Training and Technical Assistance Center (PDMP-TTAC) to provide states with a resource to assist in defining a harmonized set of healthcare access roles for PDMP data. The PDMP hospital integration indicator examined whether hospitals provided access to the PDMP within the hospital's EHR system or outside of the hospital's EHR system via a PDMP portal or secure website. In the assessment, less than half of hospitals reported integration of PDMP checks within their EHR workflows. In addition, the variability of tools used to exchange, store, and report PDMP data contributed to the complexity of PDMP 
                        <PRTPAGE P="63550"/>
                        ecosystems.
                        <SU>139</SU>
                        <FTREF/>
                         Finally, the LPASO report analyzed several standards that today support PDMP data exchange workflows, including the American Society for Automation in Pharmacy (ASAP) and Prescription Monitoring Information Exchange (PMIX) standards.
                        <SU>140</SU>
                        <FTREF/>
                         These standards, and additional standards for electronic prescribing of controlled substances (EPCS) (such as those referenced for the certification criterion in § 170.315(b)(3)), support specific capabilities that are individually well suited to the task for which they were designed. However, they are not all directly harmonized, which creates challenges when data are moving from one system and one standard to another—for example from the standard transmitted by the clinician to the pharmacy and from the pharmacy to the PDMP. The request/response messages have the same information regardless of the standards in use, but the standards have different naming conventions for the message data, making it necessary to translate requests and responses to enable seamless communication across systems.
                    </P>
                    <FTNT>
                        <P>
                            <SU>139</SU>
                             LPASO—fix citation.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>140</SU>
                             
                            <E T="03">https://www.healthit.gov/isa/allows-exchange-state-prescription-drug-monitoring-program-pdmp-data.</E>
                        </P>
                    </FTNT>
                    <P>
                        The applicable standards for the different parts of PDMP workflows are widely adopted to support pharmacy dispense reporting and interstate exchange, but further work in industry is necessary to align current standards with open, consensus-based standards, and specifically with HL7 FHIR.
                        <SU>141</SU>
                        <FTREF/>
                         The HL7 US Meds PDMP FHIR Implementation Guide is intended to define how an EHR or an app or other clinical system can access a patient's controlled substance prescription history from the State PDMP systems. This IG holds promise to advance health IT supports for PDMPs in a more interoperable manner including through new API-enabled transactions, which may also reduce the current translation challenges. However, the IG is based on the HL7 FHIR Release 3, and significant work is needed to advance, ballot, and test a version of the IG that is consistent with API standards adopted in 45 CFR 170.215.
                    </P>
                    <FTNT>
                        <P>
                            <SU>141</SU>
                             HL7 “US Meds Prescription Drug Monitoring Program (PDMP) FHIR Implementation Guide”: 
                            <E T="03">http://hl7.org/fhir/us/meds/pdmp.html.</E>
                        </P>
                    </FTNT>
                    <P>
                        While HL7 FHIR-based standards for PDMP exchange are developing and maturing, we propose to adopt functional requirements for exchanging data with PDMPs to make certain that applicable health IT can support capabilities required to engage with a PDMP meeting the requirements under Section 1944(b) of the Social Security Act, as added by Section 5042(a) of the SUPPORT Act.
                        <SU>142</SU>
                        <FTREF/>
                         These capabilities include enabling health IT systems to support integration of query into clinical workflows and to support requirements for the capability to reconcile queried data as discrete data elements (not just as read only). These requirements are also intended to enable the PDMP to respond to a query from a certified Health IT Module with discrete data. As described previously, Section 1944(b) of the Social Security Act defines specific capabilities for a PDMP to be considered a “Qualified PDMP” 
                        <SU>143</SU>
                        <FTREF/>
                         and there are capabilities that Health IT Modules could support, agnostic to a specific standard, that would be of value to enable engagement with a Qualified PDMP:
                    </P>
                    <FTNT>
                        <P>
                            <SU>142</SU>
                             Section 1944(b) of the Social Security Act [42 U.S.C. 1396w-3a] as added by section 5042(a) of the Substance Use Disorder Prevention that Promotes Opioid Recovery and Treatment for Patients and Communities Act (SUPPORT Act) of 2018 (Pub. L. 115-271).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>143</SU>
                             
                            <E T="03">Ibid.</E>
                        </P>
                    </FTNT>
                    <P>• Enabling a user to query controlled substance prescription history from their state PDMP for a specific patient.</P>
                    <P>• Enabling a user to receive a response to their PDMP queries containing patient-specific controlled substance prescribed and dispensed prescription data.</P>
                    <P>• Supporting that all transactions can be sent and received from within electronic prescribing or EPCS workflows.</P>
                    <P>
                        In order to support clinical and public health programs targeting the prevention and treatment of SUD/OUD, there are additional capabilities that Health IT Modules could support, agnostic to a specific standard, that would be of value. These include considerations of what should be a part of the PDMP (
                        <E T="03">e.g.,</E>
                         interstate query) as well as related to the PDMP indicators data placement, interpretation, access roles, and integration into clinical workflows. Based on the findings of the LPASO report for each PDMP indicator, public forums with clinical and behavioral health care providers, and the 2022 Clinical Practice Guideline recommendations, these capabilities include:
                    </P>
                    <P>• Enabling a user to query controlled substance prescription history from another state's PDMP for a specific patient.</P>
                    <P>• Enabling a user to receive a response to their interstate PDMP queries containing patient-specific controlled substance prescribed and dispensed prescription data.</P>
                    <P>• Enabling a user to validate, parse, and filter the PDMP data included in the responses received as discrete data elements—including to reconcile the data into a patient's medication list.</P>
                    <P>• Enabling access roles for clinicians and pharmacists, and with additional capabilities to create and allow customized access roles for any delegate or surrogate under applicable law such as physician assistants, nurse practitioners, and clinician delegates.</P>
                    <P>• Enabling an audit log of PDMP access.</P>
                    <P>• Enabling the use of clinical decision support tools that support clinical prescribing guideline recommendations such as those described in the 2022 Clinical Practice Guideline.</P>
                    <P>• Enabling automated or passive queries for specific common workflows consistent with state requirements and best practice guidelines</P>
                    <P>• Enabling implementation of the capabilities within other applicable workflows—such as administrative or transition of care workflows—consistent with SUD/OUD prevention and treatment best practice guidelines.</P>
                    <P>Given the current state of PDMP data exchange, we believe it is not yet feasible to adopt certification criteria leveraging the individual standards that currently support PDMP data exchange workflows. While standards developing organizations (SDOs) continue to work toward open API-enabled solutions for PDMPs, continued commitment and development effort is needed to advance FHIR-based implementation specifications to achieve readiness for widespread adoption and use.</P>
                    <P>
                        In the interim, we believe inclusion of a functional criterion within the Program may help to advance systems to support the capabilities described in the SUPPORT Act 
                        <SU>144</SU>
                        <FTREF/>
                         and implement recommendations and best practices per the 2022 Clinical Practice Guideline (
                        <E T="03">i.e.,</E>
                         Recommendation 9 to check PDMPs) as well as addressing the impact factors identified in the LPASO report. Therefore, we propose to adopt a new certification criterion to improve interoperability between health IT and PDMPs. Specifically, we propose a new certification criterion in § 170.315(f)(9) entitled “Prescription Drug Monitoring Program (PDMP) Databases—Query, receive, validate, parse, and filter.” We propose that this criterion would be a functional criterion agnostic to a specific PDMP standard, but would include transport, content, and vocabulary standards where appropriate. We additionally propose to include functional requirements for 
                        <PRTPAGE P="63551"/>
                        access controls including access roles and audit logs within this new criterion.
                    </P>
                    <FTNT>
                        <P>
                            <SU>144</SU>
                             
                            <E T="03">Ibid.</E>
                        </P>
                    </FTNT>
                    <P>We propose requirements in § 170.315(f)(9) to enable a user to query a PDMP, including bi-directional interstate exchange, to receive PDMP data in an interoperable manner, to establish access roles in accordance with applicable law, and to maintain records of access and auditable events.</P>
                    <P>We propose requirements in § 170.315(f)(9)(i) to enable both passive and active bi-directional query of a PDMP, including an interstate exchange query, and send an acknowledgement message in response to receipt of data after a query is performed. We propose requirements in § 170.315(f)(9)(i)(A) to initiate a passive or automated query upon the recording, change, or access of a medication order; upon the creation and transmission of an electronic prescription for a controlled substance; and upon entry of controlled substance medication data into a medication list or reconciliation of a medication list including controlled substance medication data. We also propose requirements in § 170.315(f)(9)(i)(B) to enable an active or user-initiated query of a PDMP including an interstate exchange query. In § 170.315(f)(9)(i)(C), we propose to send an acknowledgement message in response to receipt of data after a query is performed.</P>
                    <P>We propose requirements in § 170.315(f)(9)(ii) to enable a user to receive, validate, parse, and filter electronic PDMP information. We propose requirements in § 170.315(f)(9)(ii)(A) to enable a user to receive electronic controlled substance medication prescription transmitted through a method that conforms to the standard in § 170.202(d), from a service that has implemented the standard specified in § 170.202(a)(2); through a method that conforms to the standard in § 170.205(p)(1) when the technology is also using an SMTP-based edge protocol; and via an application programming interface in accordance with the standard specified in § 170.215(a)(1). We propose an optional capability to enable a user to receive electronic PDMP information governed by Trusted Exchange Framework and Common Agreement (TEFCA). In other words, that the Health IT Module is connected via the network enabled by TEFCA and can demonstrate that it can exchange data using it.</P>
                    <P>We propose requirements in § 170.315(f)(9)(ii)(B) to demonstrate the ability to detect valid and invalid electronic controlled substance medication prescription received. We propose requirements that a Health IT Module certified to this certification criterion include the capability to identify valid electronic controlled substance medication prescription received and process the data elements including any necessary data mapping to at least one of the versions of the USCDI standard in § 170.213 to enable use as discrete data elements, aggregation with other data, incorporation into a patient medication list, and parsing and filtering in accordance with the requirement proposed in § 170.315(f)(9)(ii)(C) described below. We also propose requirements that a Health IT Module certified to this certification criterion include the capability to: correctly interpret empty sections and null combinations; detect errors in electronic controlled substance medication prescription received, including invalid vocabulary standards and data not represented using a vocabulary standard; and record errors encountered and allow a user through at least one method to be notified of the errors produced, review the errors produced, and store or maintain error records for audit or other follow up action.</P>
                    <P>We propose requirements in § 170.315(f)(9)(ii)(C) to enable a user to parse and filter electronic PDMP information received and validated in accordance with paragraph § 170.315(f)(9)(ii)(B) at a minimum for any data element identified in at least one of the versions of the USCDI standard in § 170.213.</P>
                    <P>We propose requirements in § 170.315(f)(9)(iii) to enable access controls. This includes enabling access roles and recording access, including actions for auditable events and tamper-resistance. We propose requirements in § 170.315(f)(9)(iii)(A) to enable access roles for clinicians and pharmacists and to enable a user to customize additional roles for any delegate or surrogate under applicable law. Additionally, we propose requirements in § 170.315(f)(9)(iii)(B) to record access actions and maintain an audit log of actions.</P>
                    <P>We note that in our proposed certification criterion, we describe a passive or automated query as well as an active query. A passive or automated query is a query initiated by the system when another related action occurs—for example, a system automatically initiates a query on behalf of the clinician when the clinician uses an electronic prescribing module to send a prescription for a controlled substance. In such a case, the system may be configured to pair with a certified or non-certified Health IT Module that enables the EPCS in order to initiate the query without additional action by the clinician. An active query refers to a query of the PDMP initiated by the user to specifically query the PDMP based on their own clinical considerations. An active query might also be in conjunction with other clinical actions, but it should also enable the user to elect to initiate a query as part of other workflows such as administrative or care coordination actions. We welcome public comment on the inclusion of these query types, as well as the specific functions for which a passive query is required.</P>
                    <P>In addition, we note the inclusion of audit requirements and reference to auditable events. We propose that auditable events would include the same functions previously adopted for § 170.315(d)(2), (3), and (10). We note these include referenced standards in § 170.210(e) and (h). However, we have not proposed to specifically adopt auditable event or audit and disclosure log standards for the proposed certification criterion in § 170.315(f)(9) because the specific audit requirements vary across states, access roles, and use cases. However, we seek comment on the potential applicability of such standards for the proposed PDMP data certification criterion.</P>
                    <P>We welcome public comment on this proposal. In addition, we seek public comment specifically on the following areas:</P>
                    <P>• Should ONC consider additional functional requirements, or additional constraints on functional requirements, relating to the passive or automated query of a PDMP within EPCS or CPOE workflows?</P>
                    <P>• Should ONC consider either additional or reduced specificity within the minimum functions supporting receipt of the PDMP information as discrete data elements?</P>
                    <P>
                        • Should ONC further specify or further constrain access roles? For example, should ONC consider adding a “patient” access role to the requirements? What access roles would be most beneficial to define more clearly in any final rule or supportive sub-regulatory guidelines? 
                        <SU>145</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>145</SU>
                             
                            <E T="03">See,</E>
                             for example, access roles described in the LPASO report, March 2023 at: 
                            <E T="03">https://www.healthit.gov/sites/default/files/page/2023-03/LPASO_Landscape_Assessment_508.pdf.</E>
                        </P>
                    </FTNT>
                    <P>• Are there additional functional capabilities that would support effective SUD/OUD prevention and treatment that should be considered for a future version of the proposed certification criterion?</P>
                    <P>
                        We additionally refer readers to section III.B.13.e.ix describing a new 
                        <PRTPAGE P="63552"/>
                        proposed certification criterion in § 170.315(f)(29) that relates to this proposed certification criterion in § 170.315(f)(9).
                    </P>
                    <HD SOURCE="HD3">iii. § 170.315(f)(21) Immunization Information—Receive, Validate, Parse, Filter, and Exchange—Response</HD>
                    <P>Immunization reporting is a vital component of public health data, and is used by all 50 states, Washington DC, Puerto Rico, and many large local jurisdictions. States that have immunization information systems (IIS) consolidate immunization histories and exchange information with vaccination providers, with the goals of improving vaccination rates and reducing vaccine-preventable diseases. In order to achieve the stated goals of immunization information exchange, PHAs must have the technology in place to perform corresponding functions to certified health IT and receive the same standard included in § 170.315(f)(1).</P>
                    <P>We propose to adopt a new certification criterion for health IT for public health that would focus on immunization information—receipt, validation, parsing, and filtering—adhering to the same standard as required in § 170.315(f)(1). We further propose a requirement for responding to queries from external systems, as well as seek comment on patient access as a complement to the proposed updated requirements in § 170.315(f)(1). Such updates will provide clinicians with querying access to IISs in order to better determine the vaccination status of their patients, among other benefits. By including functions performed by health IT for public health within a certification criterion, the Program advances its focus on bi-directional interoperability between healthcare and PHAs. Such functionality for receipt, validation, query/response, and patient access should enable more users, including those using a variety of health IT systems, to have the most complete and accurate vaccine history for individuals. This functionality can help advance EHRs, IISs, and intermediaries in alignment, with the same foundational functionalities, and keep data moving with the speed of care. If an individual receives a vaccine from a pharmacy, from a community health clinic, away from their home state, or at their provider's office, any approved user regardless of their health IT should be able to have access to their complete, accurate vaccine history. We believe these proposed requirements, coupled with the proposed § 170.315(g)(20) and updates to § 170.315(f)(1), can move the nation closer to this ideal state.</P>
                    <P>These new capabilities include: receive, validate, parse, and filter incoming data in accordance with at least one of the versions of the standard and applicable implementation specification specified in § 170.205(e); transmission of immunization information electronically in accordance with at least one of the versions of the standard and applicable implementation specification in § 170.205(e); and technical capability to respond to incoming patient-level and/or immunization-specific queries from external systems. We request feedback on the functional requirement to respond to patient-level, immunization-specific queries from external systems and request comment on if the standard referenced in § 170.205(e) is sufficient for the proposed functional requirement to respond to incoming patient-level and immunization-specific queries. We seek comment on if we should also require health IT for public health to share immunization information on a population of patients using the standard specified in § 170.315(g)(20)(ii) in our proposals in section III.B.16, and whether health IT for public health should also be able to support patient access using SMART Health Cards for Immunization Criteria according to § 170.315(j)(22). We specifically request comment on readiness and feasible timelines for these capabilities.</P>
                    <P>Additionally, we recognize that due to the work and collaboration of state immunization programs, IIS vendors, CDC's National Center for Immunization and Respiratory Diseases (NCIRD), and the American Immunization Registry Association (AIRA), immunization systems can do much of what is described above already. Through these NCIRD sponsored and established programmatic requirements and optional testing programs conducted by AIRA, many IISs already meet most of, if not all, of the requirements in the proposed certification criterion. We applaud the work done already, and the intent of our proposal is to ground the certification requirements in what already exists without additional burden or cost for IISs that already participate in the NCIRD requirements. However, we know it is important to codify these functional requirements in the Program to demonstrate the success of modern approaches to data exchange and clinician access to data, and to create a shared floor of functionality for all health IT contributing to immunization information sharing.</P>
                    <P>We propose requirements in § 170.315(f)(21) to enable health IT for public health to receive, validate, parse, and filter electronic immunization information. We also propose requirements in § 170.315(f)(21) to enable health IT for public health to exchange immunization information. These proposed requirements are described below.</P>
                    <P>
                        We propose requirements in § 170.315(f)(21)(i) to enable health IT for public health to receive electronic immunization information transmitted through a method that conforms to Simple Object Access Protocol (SOAP)-based transport. Optionally, to meet the received requirements, a developer (serving as a Participant or Subparticipant of a Qualified Health Information Network
                        <SU>TM</SU>
                         (QHIN
                        <SU>TM</SU>
                        ), or who is a QHIN) may demonstrate receipt through a connection governed by the Trusted Exchange Framework and Common Agreement, receipt through a method that conforms to the standard specified in § 170.205(p)(1) when the technology is also using an Simple Mail Transfer Protocol (SMTP)-based edge protocol, or receipt via an application programming interface in accordance with the standard specified in § 170.215(a)(1) or at least one of the versions of the standard specified in § 170.215(d).
                    </P>
                    <P>We propose requirements in § 170.315(f)(21)(ii) to demonstrate the ability to detect valid and invalid electronic immunization information received and formatted in accordance with the standards specified in § 170.207(e)(5) and § 170.207(e)(6). In order to meet the validate requirements, the health IT for public health must include the capability to identify valid electronic immunization information received and process the data elements required for the standards specified in § 170.207(e)(5) and § 170.207(e)(6). Processing must include any necessary data mapping to enable use as discrete data elements, aggregation with other data, and parsing and filtering in accordance with the parse and filter requirements in the proposed § 170.315(f)(21)(iii). Additionally, in order to meet the validate requirements, the health IT for public health must correctly interpret empty sections and null combinations; detect errors in immunization information received, including invalid vocabulary standards and codes not specified in the standards specified in § 170.207(e)(5) and § 170.207(e)(6); and record errors encountered allowing a user to be notified of the errors produced, to review the errors produced, and to store or maintain error records for audit or other follow up action.</P>
                    <P>
                        We propose that Health IT Modules certified to § 170.315(f)(21)(iii) support users to parse and filter immunization 
                        <PRTPAGE P="63553"/>
                        information received and validated in accordance with validate requirements in the proposed § 170.315(f)(21)(ii) according to the standard specified in § 170.207(e)(5) or § 170.207(e)(6).
                    </P>
                    <P>We propose functional requirements in § 170.315(f)(21)(iv) to respond to both incoming patient-level and immunization-specific queries from external systems.</P>
                    <P>We welcome comment on these proposals.</P>
                    <HD SOURCE="HD3">iv. § 170.315(f)(22) Syndromic Surveillance—Receive, Validate, Parse, and Filter</HD>
                    <P>We propose to adopt a new criterion for the functional requirement to receive, validate, parse, and filter incoming syndromic surveillance information in accordance with at least one of the versions of the standards adopted in § 170.205(d) and not expired for the purposes of certification to criteria in § 170.315(f) at the time of certification. As discussed in § 170.315(f)(2), syndromic surveillance information is vital to the monitoring and early detection of potential public health events. Syndromic surveillance data help provide PHAs the information they need to prevent a public health threat from becoming a public health emergency. Further, since these threats do not respect boundaries, the cross-jurisdictional exchange and national awareness of syndromic surveillance data is vital. The transmission of information electronically, according to the standard specified in § 170.205(d), must be accompanied by the ability to receive and validate information according to the same standard in order to facilitate use of the standardized data for analysis and decision-making. Such functions—receipt and validation—are needed to reduce the need for manual effort or manipulation related to data integration and processing, and to allow for the prompt intake and analysis of information. This process also includes the recipients of reported information in the testing of the workflow at data submission, confirming that what is sent is formatted accurately and allows for validation and processing.</P>
                    <P>
                        Syndromic surveillance has proven to be a highly effective tool for detecting localized trends in outbreaks, and in larger scale monitoring for seasonal illnesses.
                        <SU>146</SU>
                        <FTREF/>
                         The National Syndromic Surveillance Program (NSSP) receives data from over 77% of non-Federal emergency departments nationwide as of July 2023, and does so via jurisdictional PHAs, using the standard specified in § 170.205(d). Many of the systems used today for such monitoring also assisted in predicting trends in the COVID-19 pandemic and estimating future spread.
                        <SU>147</SU>
                        <FTREF/>
                         The pandemic also raised the importance of certain data elements being included in the standard in order to better assess hot spots and inform response, including travel status, pregnancy status, acuity, and admission information—all of which are reflected in the updated version of the standard specified in § 170.205(d).
                    </P>
                    <FTNT>
                        <P>
                            <SU>146</SU>
                             Buehler, J.W., Sonricker, A., Paladini, M., Soper, P., &amp; Mostashari, F. (2008). Syndromic surveillance practice in the United States: findings from a survey of state, territorial, and selected local health departments. 
                            <E T="03">Advances in Disease Surveillance, 6</E>
                            (3), 1-20.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>147</SU>
                             
                            <E T="03">Ibid.</E>
                        </P>
                    </FTNT>
                    <P>We propose to require at least one of the versions of the standards and implementation specifications specified in § 170.205(d) for the receipt, validation, parsing, and filtering of incoming syndromic surveillance information. We note that given the widespread implementation of syndromic surveillance, most jurisdictions have technology that can already fulfill many of the proposed requirements. However, we believe that adopting this certification criterion for health IT for public health will reinforce the importance of a foundational functionality requirement for all syndromic surveillance systems to be able to validate and assess incoming information quickly to identify emerging threats. While receipt is a function that most syndromic surveillance systems can accomplish today, our proposal to certify this functionality for health IT for public health would allow for several additional benefits. First, it would include both sending and receiving systems in testing the shared standard, finding issues, and aligning on how to constrain specifications to limit variability. Second, it would advance syndromic surveillance technology on the same path as the systems reporting data to them, to allow all involved systems to grow and align when it comes to data exchange—eliminating the need for manual workarounds or costly third parties to fill the gaps between functionalities. Third, the coordination between sending and receiving systems would compel nationwide upgrades and transitions as public health needs and use cases evolve and shift.</P>
                    <P>We propose that consistent with at least one of the versions of the standards and implementation specifications specified in § 170.205(d), Health IT Modules certified to § 170.315(f)(22) enable a user to receive, validate, parse and filter electronic syndrome-based public health surveillance information in accordance with the proposed § 170.315(f)(22)(i) through (iii).</P>
                    <P>Specifically, we propose to require Health IT Modules certified to § 170.315(f)(22)(i) to receive electronic syndrome-based public health surveillance information transmitted through a method that conforms to a Secure File Transfer Protocol (SFTP) connection. SFTP is designed for securely moving large volumes of data, and syndromic surveillance reporting involves moving thousands of HL7 messages in a single batch. Even though this protocol does not function in real-time, unlike modern application programming interface (API)-based exchanges, and introduces the possibility of human error, this is the preferred protocol in use by NSSP for transport today and is also a key protocol supported by the current CDC architecture. Optionally, to meet the receive requirements, a developer (serving as a Participant or Subparticipant of a QHIN, or who is a QHIN) may demonstrate receipt through a connection governed by the Trusted Exchange Framework and Common Agreement or receipt via an application programming interface in accordance with the standard specified in § 170.215(a)(1) or at least one of the versions of the standard specified in § 170.215(d).</P>
                    <P>
                        We propose in § 170.315(f)(22)(ii) that Health IT Modules certified to that criterion would demonstrate the ability to detect valid and invalid electronic syndrome-based public health surveillance information received and formatted in accordance with at least one of the versions of the standards specified in § 170.205(d). To meet the validate requirements, a Health IT Module certified to this criterion must include the capability to identify valid syndrome-based public health surveillance information received and process the data elements required for at least one of the versions of the standards specified in § 170.205(d). Processing must include any necessary data mapping to enable use as discrete data elements, aggregation with other data, and parsing and filtering in accordance with parse and filter requirements in the proposed § 170.315(f)(22)(iii). A Health IT Module certified to § 170.315(f)(22) must also include the capability to correctly interpret empty sections and null combinations; detect errors in syndrome-based public health surveillance information received, including invalid vocabulary standards and codes not specified in at least one of the versions of the standards specified in § 170.205(d); and, record 
                        <PRTPAGE P="63554"/>
                        errors encountered allowing a user to be notified of the errors produced, to review the errors produced, and to store or maintain error records for audit or other follow up action.
                    </P>
                    <P>We propose that Health IT Modules certified to § 170.315(f)(22)(iii) would need to enable a user to parse and filter electronic syndrome-based public health surveillance information received and validated in accordance with the validate requirements in the proposed § 170.315(f)(22)(ii).</P>
                    <P>We welcome comment on these proposals.</P>
                    <HD SOURCE="HD3">v. § 170.315(f)(23) Reportable Laboratory Test Values/Results—Receive, Validate, Parse, and Filter</HD>
                    <P>Laboratory-based test results workflow is initiated when a clinician orders a diagnostic test for a patient who presents with symptoms related to a notifiable disease. Laboratory orders are often, but not always, initiated in EHR systems. After the order is placed, the laboratory conducts the test(s) and returns the result(s) to the clinician. The performing laboratory provides the results in various ways, but many laboratories provide the results of the test, ideally electronically, using a Laboratory Information Management Systems (LIMS) or Laboratory Information Systems (LIS). PHAs must also be able to receive the electronically transmitted reportable laboratory test values/results in their system(s) in order to conduct contact tracing, understand disease spread, and have early indications of potential outbreaks.</P>
                    <P>As described in section III.B.18, we propose a requirement in § 170.315(a)(2) that would require a user of a certified Health IT Module to be able to create and transmit laboratory orders electronically according to the standard specified in § 170.205(g)(2). We additionally propose in section III.B.13.d.iii a requirement in § 170.315(f)(3) to create laboratory tests and values/results for electronic transmission, according to specified standards.</P>
                    <P>In order to align all of the technical aspects related to reportable lab data across the different public health and health care entities involved, we propose to adopt a certification criterion in § 170.315(f)(23) to require the functionality for Health IT Modules certified to the criterion to be able to receive, validate, parse, and filter incoming reportable laboratory test values/results. By adopting a certification criterion for health IT for public health to receive results and values back electronically (according to national standards), such systems would be able to support delivering more complete patient information to clinicians throughout the laboratory workflow and to PHAs for public health action.</P>
                    <P>For reportable conditions with associated laboratory results, the laboratory is responsible for sending an electronic laboratory report to the relevant jurisdictional PHAs. We have required the ELR IG as the standard for reporting to PHAs in § 170.315(f)(3) throughout the Program. We understand that most laboratory systems already have the capability of transmitting results to PHAs according to the ELR IG, as demonstrated by the high level of connectedness of laboratories and PHAs. The PHA receiving the related laboratory result or value often, however, does not receive all of the information needed for action, such as patient demographics, creating gaps in understanding and issues with contact tracing and patient outreach to slow the spread of infectious disease. We propose the transition to the LRI IG—the public health profile—to send results to PHAs. This should enable increased completeness of data for public health action.</P>
                    <P>Accordingly, and consistent with at least one of the standards in § 170.205(g)(1) and (3), we propose requirements in § 170.315(f)(23) to enable Health IT Modules certified to the criterion to receive, validate, parse, and filter electronic reportable laboratory test values/results according to either the ELR IG or the LRI IG as described below. We propose that either standard will meet this requirement until the ELR IG expires on January 1, 2028, and we propose a transition to the LRI IG after that date. We note that because § 170.205(g) includes the expiration dates for the applicable standards, they are not duplicated within this certification criterion. We request comment on if this timeline is feasible for this transition.</P>
                    <P>We propose requirements in § 170.315(f)(23)(i) to receive electronic reportable laboratory test values/results transmitted at a minimum through a method that conforms to the standards specified in § 170.202(d), from a service that has implemented the standard specified in § 170.202(a)(2); and, through a method that conforms to the standard in § 170.205(p)(1) when the technology is also using an SMTP-based edge protocol. Optionally, to meet the receive requirements, a developer (serving as a Participant or Subparticipant of a QHIN, or who is a QHIN) may demonstrate receipt through a connection governed by the Trusted Exchange Framework and Common Agreement, or receipt via an application programming interface in accordance with the standard specified in § 170.215(a)(1) or at least one of the standards specified in § 170.215(d).</P>
                    <P>We propose requirements in § 170.315(f)(23)(ii) to demonstrate the ability to detect valid and invalid electronic reportable laboratory test values/results received and formatted consistent with the standard in § 170.205(g)(1) or the Public Health Profile within the implementation specification in § 170.205(g)(3). To meet the validate requirements, health IT for public health must include the capability to identify valid electronic reportable laboratory test values/results received and process the data elements as required by the standard in § 170.205(g)(1) or the standard in § 170.205(g)(3). Processing must include any necessary data mapping to enable use as discrete data elements, aggregation with other data, and parsing and filtering in accordance with parse and filter requirements in the proposed § 170.315(f)(23)(iii). Health IT for public health must also include the capability to correctly interpret empty sections and null combinations; detect errors in electronic reportable laboratory test values/results received including invalid vocabulary standards and codes not specified in the § 170.205(g)(1) or (3) standards; and record errors encountered allowing a user to be notified of the errors produced, to review the errors produced, and to store or maintain error records for audit or other follow up action.</P>
                    <P>We propose requirements in § 170.315(f)(23)(iii) to enable Health IT Modules certified to the criterion to parse and filter electronic reportable laboratory values/results received and validated in accordance with validate requirements in the proposed § 170.315(f)(23)(ii). We welcome comment on these proposals.</P>
                    <HD SOURCE="HD3">vi. § 170.315(f)(24) Cancer Pathology Reporting—Receive, Validate, Parse, and Filter</HD>
                    <P>
                        We propose to adopt a new certification criterion that is focused specifically on health IT for public health's ability to receive and validate incoming cancer pathology reports according to the proposed standard in § 170.205(i)(4), Cancer Pathology Data Sharing 1.0.0—STU1 and require conformance with its requirements across the certification criterion. As stated in the discussion above regarding proposed revisions to § 170.315(f)(4), cancer reporting informs cancer control efforts, including programs for preventative interventions. An 
                        <PRTPAGE P="63555"/>
                        important component of diagnosing cancer, and particularly in understanding how advanced cases are at the point of diagnosis, is pathology reporting. In section III.B.13.d.iv.4 above, we propose to include cancer pathology reporting as a component of the transmission to cancer registry certification criteria in § 170.315(f)(4). For cancer registries to receive, validate, parse, and filter these reports according to the required standard, we propose to include an accompanying requirement for the receipt, validation, parsing, and filtering of cancer pathology reports in § 170.315(f)(24). Our proposal not only would support cancer registries in having the functionality to accept information in the same standard as sending systems, but it would help sending and receiving health IT progress at the same rate, with aligned functionality.
                    </P>
                    <P>
                        CDC's National Program of Cancer Registries has been actively working with state PHAs and pathology partners, including the College of American Pathologists (CAP), to develop and pilot a FHIR Implementation Guide for cancer pathology reporting. Early results of these pilots demonstrate that use of FHIR by all involved systems will reduce the need for manual intervention and data cleansing, aid in more timely reporting, and include more complete information, including the demographic information needed to confirm reporting is happening within the patient's state of residence, rather than the state of treatment, as well as for patient matching.
                        <E T="51">148 149</E>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>148</SU>
                             Blumenthal W, Alimi TO, Jones SF, Jones DE, Rogers JD, Benard VB, Richardson LC. Using informatics to improve cancer surveillance. J Am Med Inform Assoc. 2020 Jul 1;27(9):1488-1495. doi: 10.1093/jamia/ocaa149. PMID: 32941600; PMCID: PMC7647312.
                        </P>
                        <P>
                            <SU>149</SU>
                             Ayaz M, Pasha MF, Alzahrani MY, Budiarto R, Stiawan D. The Fast Health Interoperability Resources (FHIR) Standard: Systematic Literature Review of Implementations, Applications, Challenges and Opportunities. JMIR Med Inform. 2021 Jul 30;9(7):e21929. doi: 10.2196/21929. Erratum in: JMIR Med Inform. 2021 Aug 17;9(8):e32869. PMID: 34328424; PMCID: PMC8367140.
                        </P>
                    </FTNT>
                    <P>The inclusion of receipt, validation, parsing, and filtering of electronic cancer pathology reporting in the Program would result in more complete, accurate diagnostic information being received by state cancer registries, and contribute to data analysis and early preventative intervention.</P>
                    <P>We propose that consistent with the standard(s) and implementation specification(s) specified in § 170.205(i)(4), Health IT Modules certified to § 170.315(f)(24) enable a user to receive, validate, parse and filter cancer pathology reports in accordance with the proposed § 170.315(f)(24)(i) through (iii).</P>
                    <P>We propose requirements in § 170.315(f)(24)(i) to receive electronic cancer pathology reports transmitted via an application programming interface in accordance with the standard specified in § 170.215(a)(1) or at least one of the versions of the standard specified in § 170.215(d). Optionally, to meet the receive requirements, a developer (serving as a Participant or Subparticipant of a QHIN, or who is a QHIN) may demonstrate receipt through a connection governed by the Trusted Exchange Framework and Common Agreement.</P>
                    <P>We propose requirements in § 170.315(f)(24)(ii) to demonstrate the ability to detect valid and invalid electronic cancer pathology reports received and formatted in accordance with the standards specified in § 170.205(i)(4). To meet the validate requirements, Health IT Modules certified to the criterion must include the capability to identify valid electronic cancer pathology reports and process the data elements required for the standards specified in § 170.205(i)(4). Processing must include any necessary data mapping to enable use as discrete data elements, aggregation with other data, and parsing and filtering in accordance with parse and filter requirements in the proposed § 170.315(f)(24)(iii). Health IT Modules certified to the criterion must also include the capability to correctly interpret empty sections and null combinations; detect errors in electronic cancer pathology reports received, including invalid vocabulary standards and codes not specified in the standards specified in § 170.205(i)(4); and, record errors encountered allowing a user to be notified of the errors produced, to review the errors produced, and to store or maintain error records for audit or other follow up action.</P>
                    <P>We propose requirements in § 170.315(f)(24)(iii) to enable Health IT Modules certified to the criterion to parse and filter electronic reportable cancer pathology reports received and validated in accordance with the validate requirements proposed in § 170.315(f)(24)(ii).</P>
                    <P>We welcome feedback on these proposals.</P>
                    <HD SOURCE="HD3">vii. § 170.315(f)(25) Electronic Case Reporting—Receive, Validate, Parse, Filter Electronic Initial Case Reports and Reportability Response; and Create and Transmit Reportability Response</HD>
                    <P>Case reporting is a vital component of public health surveillance and case management. Case reports act as early notification of emerging infectious disease outbreaks, as well as early indicators of other threats. For example, case reports demonstrating a rise in human rabies cases could help public health officials understand if there are problems in the local animal population. Case reporting goes beyond COVID-19 and public health emergencies and serves as a key activity to assess, monitor, investigate, and address disease in the community. Therefore, case reporting requires solutions be in place to support these foundational public health services. These activities are achieved by getting data reliably and consistently into health IT for public health for action.</P>
                    <P>In the HTI-1 Final Rule, we finalized requirements in § 170.315(f)(5) for compliance with either the CDA or the FHIR IGs for electronic case reporting to PHAs (89 FR 1226 through1231). However, in section III.B.13.d.v of this proposed rule, we propose updating the § 170.315(f)(5) certification criterion and its standards conformance requirements specified in § 170.205(t) to require adherence only to the HL7 eCR FHIR IG to be updated and provided by December 31, 2027, as part of a predictable multi-year strategy to facilitate the transition from CDA or FHIR to just FHIR. We believe adherence to a single standard, particularly the FHIR IG, will encourage consistent implementation and lead to greater interoperability compared to referencing multiple standards. Upgrading health IT for public health to support APIs and FHIR payload, as included in the HL7 FHIR eCR IG, creates greater flexibility to respond to emergency issues. Improvements in consistent implementation and interoperability would enable PHAs to have an improved picture of where and when disease outbreaks occur.</P>
                    <P>
                        Based on feedback we have heard from PHAs and other public health partners that there are current challenges with technology in place at PHAs to receive, validate, parse, and filter incoming electronic case reports, we recognize that the eCR paradigm's newness for PHAs will mean that it will likely take time to fully utilize the data in public health surveillance systems and registries. Because of the variations and inconsistencies in electronic case reports received from Health IT Modules, PHAs often take manual steps and use additional tools in order to be able to parse case reports. Incoming information frequently needs to be re-formatted and filtered, among other steps, for it to be usable to conduct case investigations. Such steps reduce 
                        <PRTPAGE P="63556"/>
                        efficiency and have the potential to delay time-sensitive public health action.
                    </P>
                    <P>We propose to adopt a certification criterion for health IT for public health that focuses on the receipt, validation, parsing, and filtering of electronic case reports and reportability response and creation and transmission of the RR according to at least one of the standards referenced in § 170.205(t). Technology in place at PHAs for case reporting and surveillance must be able to receive, validate, parse, and filter electronic case reports, as well as create and electronically transmit RRs. This requirement should reduce burden on PHAs associated with processing reported data and reduce the need for manual intervention. Further, it advances the health IT for public health that receives reported data to align with the technology that transmits the reports, adhering to the same foundational functions and standards. Supporting this alignment allows the industry to advance in harmony and creates a more scalable infrastructure in daily activities as well as in times of emergency.</P>
                    <P>
                        We note that some PHAs use intermediaries or shared service tools to implement components of the proposed certification criterion. As noted in relied upon software guidance, developers can demonstrate conformance with certification criteria requirements by developing the necessary functionality themselves or by relying on the functionality provided by a different software developer.
                        <SU>150</SU>
                        <FTREF/>
                         While we do not have the ability to require, or provide incentives for, PHAs to adopt certified Health IT Modules, other entities (
                        <E T="03">e.g.,</E>
                         another Federal or state agency) could choose to do so.
                    </P>
                    <FTNT>
                        <P>
                            <SU>150</SU>
                             
                            <E T="03">https://www.healthit.gov/sites/default/files/relieduponsoftwareguidance.pdf.</E>
                        </P>
                    </FTNT>
                    <P>We propose that consistent with at least one of the standards and implementation specifications specified in § 170.205(t), Health IT Modules certified to § 170.315(f)(25) enable a user to receive, validate, parse, and filter electronic case reporting information in accordance with the proposed § 170.315(f)(25)(i) through (iii), and to create and transmit a reportability response in accordance with the proposed § 170.315(f)(25)(iv).</P>
                    <P>We propose requirements in § 170.315(f)(25)(i) to receive electronic case reports and reportability responses transmitted via an application programming interface in accordance with the standard specified in § 170.215(a)(1) or at least one of the versions of the standard specified in § 170.215(d). Optionally, to meet the receive requirements a developer (serving as a Participant or Subparticipant of a QHIN, or who is a QHIN) may demonstrate receipt through a connection governed by the Trusted Exchange Framework and Common Agreement; or through a method that conforms to the standard specified in § 170.205(p)(1) when the technology is also using an SMTP-based edge protocol.</P>
                    <P>We propose requirements in § 170.315(f)(25)(ii) to demonstrate the ability to detect valid and invalid electronic case reporting information received and formatted in accordance with at least one of the § 170.205(t) standards. To meet the validate requirements, Health IT Modules certified to the certification criterion must include the capability to identify valid electronic case reporting information received and process the data elements for, at a minimum, the data classes expressed in at least one of the versions of the USCDI standard specified in § 170.213. Processing must include any necessary data mapping to enable use as discrete data elements, aggregation with other data, and parsing and filtering in accordance with parse and filter requirements in proposed § 170.315(f)(25)(iii). Health IT Modules certified to the criterion must also include the capability to correctly interpret empty sections and null combinations; detect errors in electronic case reporting information received including invalid vocabulary standards and codes not specified in the § 170.205(t) standards; and record errors encountered allowing a user to be notified of the errors produced, to review the errors produced, and to store or maintain error records for audit or other follow up action.</P>
                    <P>We propose requirements in § 170.315(f)(25)(iii) to enable Health IT Modules certified to the criterion to parse and filter electronic case reporting information received and validated in accordance with validate requirements in the proposed § 170.315(f)(25)(ii) of this section, at a minimum, for any data element identified in at least one of versions of the USCDI standard specified in § 170.213.</P>
                    <P>We propose requirements in § 170.315(f)(25)(iv) to enable a user to create and transmit a response in accordance with the RR profile in the HL7 eCR FHIR IG in § 170.205(t)(1).</P>
                    <P>We welcome comments on these proposals.</P>
                    <HD SOURCE="HD3">viii. § 170.315(f)(28)—Birth Reporting—Receive, Validate, Parse, and Filter</HD>
                    <P>As discussed earlier in the section regarding proposed revisions to § 170.315(f)(8), the process of birth reporting has traditionally relied on a provider manually entering data into a web portal, which is used by the jurisdiction's office of vital statistics to produce a birth certificate and report selected data items to CDC's National Center for Health Statistics. Birth reporting helps inform public health programs on important health indicators, including birth rates and infant mortality rates, is used for research, and is used to produce the birth certificates needed for proof of identification, accessing benefits, and other administrative purposes. Our proposal for § 170.315(f)(8) would provide an electronic birth reporting option—that could greatly reduce manual effort if adopted—using the new proposed standard in § 170.205(v).</P>
                    <P>In order to create alignment between sending and receiving systems, we propose a technical capability for health IT for public health to demonstrate the receipt, validation, parsing, and filtering of incoming birth reports according to the standard referenced in § 170.205(v). Adopting a certification criterion to demonstrate receiving birth reports, and that such technology can do so according to the specified standard, could reduce implementation and maintenance burden and lead to greater consistency and completeness in the reported information.</P>
                    <P>
                        While most states have adopted an electronic birth registry system (EBRS), these systems today are primarily portal-based, requiring birth information to be entered manually into electronic forms.
                        <SU>151</SU>
                        <FTREF/>
                         As described earlier in this proposal, current workflows involve dual-entry based processes. Despite investments made by CDC towards standards-based exchange with EBRS, there remains a gap in jurisdictional office of vital statistics' ability to receive and integrate data within applicable health IT for public health, particularly for data received using FHIR-based standards.
                    </P>
                    <FTNT>
                        <P>
                            <SU>151</SU>
                             National Research Council (US) Committee on National Statistics. Vital Statistics: Summary of a Workshop. Washington (DC): National Academies Press (US); 2009. B, The U.S. Vital Statistics System: A National Perspective. Available from: 
                            <E T="03">https://www.ncbi.nlm.nih.gov/books/NBK219884/.</E>
                        </P>
                    </FTNT>
                    <P>
                        In consultation with CDC and its programmatic experience, we understand that there has been low implementation of the CDA-based IG as documented by CDC programs, and significant progress has been made on 
                        <PRTPAGE P="63557"/>
                        testing and piloting of the FHIR IG for birth reporting. As a result, we propose to adopt the FHIR-based approach (as referenced in the proposed § 170.205(v)) for receipt of birth reporting. Adoption of the FHIR-based approach would align the health IT used by public health receiving birth reports with those sending birth reports. Inclusion of the ability to receive and validate FHIR-specific birth reporting within applicable health IT for public health will also provide a baseline set of capabilities that vendors of health IT for public health can build on as additional FHIR-based approaches emerge for public health, including bulk import of data and FHIR Questionnaires. The receipt of FHIR formatted birth records also supports investments being made by CDC to receive FHIR messages downstream through the Data Modernization Initiative.
                        <SU>152</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>152</SU>
                             
                            <E T="03">https://www.cdc.gov/surveillance/data-modernization/technologies/cdc-front-door.html.</E>
                        </P>
                    </FTNT>
                    <P>
                        However, as discussed in section III.B.13.e.i, due to the minimal adoption of the FHIR IG, we propose and seek comment on if we should adopt an interim standards-agnostic functional criterion for electronically transmitting selected medical and health information from birth certificate reports to PHAs based on the data elements outlined in CDC's National Vital Statistics System's “Guide to Completing the Facility Worksheets for the Certificate of a Live Birth and Report of Fetal Death.” 
                        <SU>153</SU>
                        <FTREF/>
                         We seek comment from those who have implemented and used the FHIR IG on its readiness for nationwide adoption. We further seek comment on—if we were to adopt a functional criterion—whether such a criterion should be time-limited to transition to a standards-based criterion as of a specific timeline, for example at 24 months after the timeline for implementation of any such functional criterion.
                    </P>
                    <FTNT>
                        <P>
                            <SU>153</SU>
                             
                            <E T="03">https://www.cdc.gov/nchs/nvss/facility-worksheets-guide.htm.</E>
                        </P>
                    </FTNT>
                    <P>We propose that consistent with the standard(s) and implementation specification(s) specified in § 170.205(v), Health IT Modules certified to § 170.315(f)(28) enable a user to receive, validate, parse, and filter birth reporting information in accordance with the proposed § 170.315(f)(28)(i) through (iii).</P>
                    <P>We propose requirements in § 170.315(f)(28)(i) to receive electronic birth reports transmitted via an application programming interface in accordance with the standard specified in § 170.215(a)(1) or at least one of the versions of the standard specified in § 170.215(d). Optionally, to meet the receive requirements a developer (serving as a Participant or Subparticipant of a QHIN, or who is a QHIN) may demonstrate receipt through a connection governed by the Trusted Exchange Framework and Common Agreement; receipt through a method that conforms to the standard specified in § 170.202(d), from a service that has implemented the standard specified in § 170.202(a)(2); or, receipt through a method that conforms to the standard in § 170.205(p) when the technology is also using an SMTP-based edge protocol.</P>
                    <P>We propose requirements in § 170.315(f)(28)(ii) to demonstrate the ability to detect valid and invalid electronic birth reports received and formatted in accordance with the standards specified in § 170.205(v). To meet the validate requirements, Health IT Modules certified to the criterion must include the capability to identify valid electronic birth reports received and process the data elements required for the standards specified in § 170.205(v). Processing must include any necessary data mapping to enable use as discrete data elements, aggregation with other data, and parsing and filtering in accordance with parse and filter requirements proposed in § 170.315(f)(28)(iii). Health IT Modules certified to the criterion must also include the capability to correctly interpret empty sections and null combinations; detect errors in electronic birth reports received including invalid vocabulary standards and codes not specified in the standards specified in § 170.205(v); and record errors encountered allowing a user to be notified of the errors produced, to review the errors produced, and to store or maintain error records for audit or other follow up action.</P>
                    <P>We propose requirements in § 170.315(f)(28)(iii) to enable Health IT Modules certified to the criterion to parse and filter electronic birth reports received and validated in accordance with validate requirements in the proposed § 170.315(f)(28)(ii).</P>
                    <P>We welcome comment on these proposals.</P>
                    <HD SOURCE="HD3">ix. § 170.315(f)(29)—Prescription Drug Monitoring Program (PDMP) Data—Receive, Validate, Parse, Filter Prescription Data, Support Query and Exchange</HD>
                    <P>
                        We propose to introduce a functional certification criterion focused on the ability of health IT for public health to receive and validate reported PDMP information, to respond to queries from providers or other PDMP databases and hubs, and to initiate queries to those other PDMP databases and hubs. As mentioned in the earlier discussion regarding a new proposed certification criterion in § 170.315(f)(9), a provider's ability to query information from a PDMP “can help identify patients who may be at risk for overdose.” 
                        <SU>154</SU>
                        <FTREF/>
                         PDMP data can also “be helpful when patient medication history is unavailable and when care transitions to a new clinician.” 
                        <SU>155</SU>
                        <FTREF/>
                         To complement our proposal to support certification of health IT used by providers to be capable of requesting data from PDMP databases, we also believe it is important to certify the capability of health IT for public health, in this case PDMPs, to respond to queries submitted. While it is expected that most PDMPs support this requirement today, inclusion of the functionality in the Program will support PDMPs capabilities in alignment with requirements for health IT systems to request and validate PDMP information. Our proposal will also require that functionality is based on open, consensus-based practices where possible, allowing PDMPs to have the ability to exchange information without undue burden. Additionally, PDMPs should have the capability to support interstate data sharing (or queries) to better inform prescribing practices, improve patient care and safety, monitor patient behaviors that contribute to the opioid epidemic, and facilitate a nimble and targeted response.
                    </P>
                    <FTNT>
                        <P>
                            <SU>154</SU>
                             
                            <E T="03">https://www.cdc.gov/opioids/healthcare-professionals/pdmps.html.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>155</SU>
                             
                            <E T="03">Id.</E>
                        </P>
                    </FTNT>
                    <P>
                        Concerns have been raised within the health IT industry regarding the lack of interoperability between different systems and data hubs involved in interstate queries, and these concerns have hindered policy objectives described in several statutes to address the opioid crisis. A lack of consistent interoperability requirements between PDMPs, systems, and data hubs involved in interstate exchange makes such queries burdensome on both the querying and responding systems. Inclusion of a functional certification criterion in the Program in § 170.315(f)(29) would help states conform to functionalities specified in section 1944(b) of the Social Security Act, as added by section 5042(a) of the SUPPORT Act,
                        <SU>156</SU>
                        <FTREF/>
                         to support interjurisdictional query and response, and to receive and validate data into health IT. Further, this approach is 
                        <PRTPAGE P="63558"/>
                        aligned with CMS requirements on funding state systems in 42 CFR 433.112(b)(10), which specify the conditions that a system must meet, including the “Use [of] a modular, flexible approach to systems development, including the use of open interfaces and exposed application programming interfaces . . .”
                    </P>
                    <FTNT>
                        <P>
                            <SU>156</SU>
                             Section 1944(b) of the Social Security Act [42 U.S.C. 1396w-3a] as added by section 5042(a) of the Substance Use Disorder Prevention that Promotes Opioid Recovery and Treatment for Patients and Communities Act (SUPPORT Act) of 2018 (Pub. L. 115-271).
                        </P>
                    </FTNT>
                    <P>
                        We also propose that Health IT Modules certified to this criterion be able to receive and validate data reported in a manner consistent with the PDMP technology transmitting, reporting, or querying that data. As expressed elsewhere within this proposal, while PDMP technology currently is capable of receiving and validating data, we believe it is necessary to include functionality for PDMP technology to support the receipt of information in accordance with section 1944(b) of the Social Security Act, as added by section 5042(a) of the SUPPORT Act,
                        <SU>157</SU>
                        <FTREF/>
                         and that PDMP technology can accept data according to the same functionality required for transmission under § 170.315(f)(9).
                    </P>
                    <FTNT>
                        <P>
                            <SU>157</SU>
                             
                            <E T="03">Ibid.</E>
                        </P>
                    </FTNT>
                    <P>As stated in section III.B.13.e.ii, we believe that further work in the health IT industry is necessary to align current consensus-based standards, specifically FHIR. We also believe that previously described projects to map current standards to FHIR will greatly benefit functionality proposed here, specifically regarding the exchange of information between PDMPs. While HL7 FHIR-based standards are developing and maturing, we propose a set of functional criteria for receiving and validating reported data and initiating and responding to queries from applicable health IT, including other state PDMPs, to support applicable health IT capabilities that may be utilized to meet requirements under section 1944(b) of the Social Security Act, as added by section 5042(a) of the SUPPORT Act.</P>
                    <P>As described above in section III.B.13.e.ii, section 1944(b) of the Social Security Act, as added by section 5042(a) of the SUPPORT Act, describes a Qualified PDMP, with respect to a State, as a program which, at a minimum, satisfies the following two criteria. First, the program facilitates access by a covered provider to, at a minimum, the following information with respect to a covered individual, in as close to real-time as possible: information regarding the prescription drug history of a covered individual with respect to controlled substances; the number and type of controlled substances prescribed to and filled for the covered individual during at least the most recent 12-month period; and the name, location, and contact information (or other identifying number selected by the State, such as a national provider identifier issued by the National Plan and Provider Enumeration System of the Centers for Medicare &amp; Medicaid Services) of each covered provider who prescribed a controlled substance to the covered individual during at least the most recent 12-month period. Second, the program facilitates the integration of information described in the first criteria above into the workflow of a covered provider, which may include the electronic system the covered provider uses to prescribe controlled substances.</P>
                    <P>
                        Section 1944(f) of the Social Security Act, as added by section 5042(a) of the SUPPORT Act, includes an increase to Federal Medical Assistance Percentage (FMAP) and Federal Matching Rates for Certain Expenditures Relating to Qualified Prescription Drug Monitoring Programs under Section 1903(a).
                        <SU>158</SU>
                        <FTREF/>
                         The requirements proposed in § 170.315(f)(29) are, therefore, written to be consistent with the Section 1903(a) funding requirements in 42 CFR 433.112. Specifically, §§ 433.112(b)(10) and (12) include requirements for the use of open interfaces and exposed application programming interfaces, and alignment with, and incorporation of, standards and implementation specifications for health information technology adopted by the Office of the National Coordinator for Health IT in 45 CFR part 170, subpart B. Section 433.112(b)(16) also requires interoperability with health information exchanges, public health agencies, human services programs, and community organizations providing outreach and enrollment assistance services as applicable.
                    </P>
                    <FTNT>
                        <P>
                            <SU>158</SU>
                             Section 1944(f) of the Social Security Act [42 U.S.C. 1396w-3a] as added by section 5042(a) of the Substance Use Disorder Prevention that Promotes Opioid Recovery and Treatment for Patients and Communities Act (SUPPORT Act) of 2018 (Pub. L. 115-271).
                        </P>
                    </FTNT>
                    <P>We propose requirements in § 170.315(f)(29) to enable technology to receive, validate, parse, and filter electronic prescription information for controlled substance medications and support query and exchange of PDMP data as described below.</P>
                    <P>We propose requirements in § 170.315(f)(29)(i) to receive electronic controlled substance medication prescription information transmitted through a method that conforms to the standard in § 170.202(d), from a service that has implemented the standard specified in § 170.202(a)(2); through a method that conforms to the standard in § 170.205(p)(1) when the technology is also using an SMTP-based edge protocol; and, via an application programming interface in accordance with the standard specified in § 170.215(a)(1) or at least of the versions of the standard specified in § 170.215(d). Optionally, to meet the receive requirements, a developer may demonstrate receipt through a connection governed by the Trusted Exchange Framework and Common Agreement.</P>
                    <P>We propose requirements in § 170.315(f)(29)(ii) to demonstrate the ability to detect valid and invalid electronic controlled substance medication prescription information received. To meet the validate requirements, the Health IT Module certified to this criterion must include the capability to identify valid electronic controlled substance medication prescription information received and process the data elements including any necessary data mapping or translation between standards. The Health IT Module certified to this criterion must also include the capability to correctly interpret empty sections and null combinations; detect errors in electronic controlled substance medication prescription information received, including invalid vocabulary standards and codes; and record errors encountered allowing a user to be notified of the errors produced, to review the errors produced, and to store or maintain error records for audit or other follow up action.</P>
                    <P>We propose requirements in § 170.315(f)(29)(iii) to enable a user to parse and filter electronic controlled substance medication prescription information received and validated in accordance with requirements in the proposed § 170.315(f)(29)(ii).</P>
                    <P>We propose requirements in § 170.315(f)(29)(iv) to enable patient-level query and exchange. The proposed requirement is to enable patient-level queries from external systems of electronic controlled substance medication prescription information of the PDMP including an interstate exchange query. This proposed requirement includes exchange—response requirements to respond to incoming patient-level queries from external systems and exchange—patient access requirements to enable patient access to view electronic controlled substance medication prescription information.</P>
                    <P>
                        We welcome public comment on this proposed new certification criterion.
                        <PRTPAGE P="63559"/>
                    </P>
                    <HD SOURCE="HD3">f. New Standardized API for Public Health Data Exchange</HD>
                    <HD SOURCE="HD3">i. Background</HD>
                    <P>Despite advances made over the last decade in public health data exchange and health IT interoperability, challenges and gaps remain in exchange capabilities and technical infrastructure. Current efforts have been hampered by a history of bespoke solutions and a multitude of projects, contracts, and implementations that struggled to scale or sustain adequate funding, limiting adoption of resulting standards or implementation guides. This limited adoption of standards and mechanisms for electronic public health data exchange, among other challenges, has resulted in poor interoperability that often relies on manual effort, such as phone calls, faxes, and data entry.</P>
                    <P>The COVID-19 pandemic stressed our public health system and surfaced flaws in the data that public health officials obtain from health care providers—both in the data itself, but also the ways in which data are reported. As a result, public health officials' access to critical health data during public health emergencies or disasters lags, and their experience varies with respect to the use of technology to glean insights to inform decisions on quarantines, hospital capacity, public health education campaigns, distribution of critical medical supplies, school closures, reopening after a pandemic, and many other essential public health decisions.</P>
                    <P>Without modern standards and consistent requirements to adopt standards-based IT systems, public health data exchange often relies on custom, siloed solutions, and manual workarounds. Currently, most public health data exchange relies on older versions of HL7 v2 or CDA standards. HL7 v2 and CDA standards support simple, single-patient, event-based submission of documents from healthcare to PHAs, but these standards do not adequately support more complex data exchange use cases, such as bulk exchange of patients who received a specific vaccine. However, now that the majority of hospitals and office-based clinicians nationwide have adopted FHIR-based APIs with Health IT Modules certified to § 170.315(g)(10) for patient and population level services, the technical landscape has evolved, and today's health IT infrastructure presents the public health ecosystem with vastly improved options to engage in more granular data exchange. The shift to HL7 FHIR is needed to support a wide-scale public health response, and we believe broad adoption of HL7 FHIR would reduce burden of implementation and maintenance for data exchange between and among healthcare organizations, providers, and PHAs.</P>
                    <P>
                        The following describes our proposal to adopt a new certification criterion in § 170.315(g)(20) that would establish requirements for a standardized HL7 FHIR-based API for public health data exchange and extend the capabilities included in the standardized API for patient and population services in § 170.315(g)(10). This new certification criterion would support ongoing and future development of public health FHIR IGs leveraging a core set of existing, modular, and extensible capabilities and standards. Standards referenced in the proposed § 170.315(g)(20) support FHIR capabilities such as API-based event notifications (
                        <E T="03">i.e.,</E>
                         HL7 FHIR Subscriptions), SMART App Launch, and Bulk Data Export. Our proposals in § 170.315(g)(20) would also include constrained, specific requirements for health IT for public health such as compliance with the United States Public Health Profiles Library Implementation Guide (USPHPL IG), referenced in the proposed § 170.215(b)(2).
                    </P>
                    <P>We propose this approach for several reasons. First, we believe that establishing a standardized API for public health data exchange is a necessary first step towards furthering a FHIR-based ecosystem that would support a wide array of public health data exchange use cases, including those established in the Program currently, those being proposed as new certification criteria in the Program, and for future use cases. Importantly, we believe that a FHIR-based ecosystem will better streamline and reduce reporting burden for healthcare organizations and developers, while expanding PHA's access to critical data for action, such as identification of at-risk or infected individuals during an outbreak.</P>
                    <P>
                        Second, we believe that a standard API for public health data exchange—with a consistent set of standards-based functionalities and capabilities for Health IT Modules certified to the § 170.315(g)(20) certification criterion—would support innovation and longer-term public health modernization and would establish baseline capabilities for public health use cases. The consistent functionalities established in the combination of § 170.315(g)(10) and § 170.315(g)(20) would support the creation or revision of health IT for public health IGs necessary to advance interoperability for specific use cases, such as cancer pathology reporting, which has a draft FHIR IG, or immunization reporting, which is currently only supported by a HL7 v2-based IG. Using HL7 FHIR-based APIs, PHAs and healthcare partners could create an ecosystem where health IT for public health can securely query data directly from the source, in real time, when needed, based on an initial push of relevant data. Helios tested this approach and participants were able to successfully query EHRs for additional patient-level information after an initial trigger, and we are working with CDC to pilot and scale this approach.
                        <SU>159</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>159</SU>
                             
                            <E T="03">https://confluence.hl7.org/display/FHIR/2024+-+01+Helios+Query+and+Response+Track.</E>
                        </P>
                    </FTNT>
                    <P>Third, we believe that the proposed certification criterion in § 170.315(g)(20) would serve as a glidepath towards an eventual transition to broader HL7 FHIR-based reporting for public health data exchange. We propose that Health IT Modules certified to § 170.315(g)(20) would support modular and foundational capabilities and standards, such server support for subscriptions in § 170.315(j)(23), and support a public health specific set of HL7 FHIR profiles that extend the requirements in § 170.315(g)(10) to support a public health transition to HL7 FHIR.</P>
                    <P>Finally, we believe this approach will minimize development burden by relying heavily on the standards and capabilities already required of Health IT Modules certified to § 170.315(g)(10), while supporting near-term development and authoring of public health use case-specific HL7 FHIR IGs, where necessary, to transmit relevant data to PHAs. We emphasize for clarity that just because we propose to adopt a public health-focused API certification criterion in § 170.315(g)(20), developers of certified health IT are not required to build one API per criterion (if they are also certified to § 170.315(g)(10) for example). Developers of certified health IT would have flexibility to certify and deploy APIs scoped however they want, if and as they certify Health IT Modules to multiple API-based certification criteria, including those proposed to be included as part of the Base EHR definition in § 170.102, including certification criteria in § 170.315(g)(10), (g)(20), (g)(30) and (g)(34).</P>
                    <P>
                        We believe that this rulemaking is necessary to set the stage for our long-term strategy to advance public health data modernization in partnership with CDC. We anticipate that requirements to support a standard API for public health exchange would lead to increased capacity for data exchange and spur additional pilots. As use case-specific HL7 FHIR IGs are authored for specific 
                        <PRTPAGE P="63560"/>
                        data exchange needs and are refined through successful pilots and approved for widespread adoption by relevant standards development organizations, we intend to consider referencing these HL7 FHIR IGs in future rulemaking. We will continue to work with partners, such as Helios—the public health FHIR accelerator made up of ONC, CDC, PHAs, health IT vendors, and HL7—to support PHAs in more easily receiving and accessing data to further their numerous objectives and missions.
                    </P>
                    <HD SOURCE="HD3">ii. Adoption of Generalizable and Public Health-Specific Standards and Functionality in the Standardized API for Public Health Data Exchange</HD>
                    <P>We propose to adopt some of the functional and standards-based requirements from our existing requirements in § 170.315(g)(10) as part of the certification criterion proposed in § 170.315(g)(20). For example, in § 170.315(g)(10), section III.B.19, we propose to rely on modular functionalities proposed and described in proposed § 170.315(j) to support both functional and dynamic registration, authentication and authorization for system access, and we propose to rely on HL7 FHIR-based IGs familiar to developers of certified health IT with Health IT Modules certified to § 170.315(g)(10), such as the SMART App Launch IG in § 170.215(c), and the FHIR Bulk Data Access IG in § 170.215(d). We also propose that Health IT Modules certified to § 170.315(g)(20) support new subscriptions capabilities proposed in § 170.315(j)(23), and we propose that Health IT Modules certified to § 170.315(g)(20) support HL7 FHIR Resources as profiled by the USPHPL IG proposed in § 170.215(b)(2).</P>
                    <P>Specifically, we propose that Health IT Modules certified to § 170.315(g)(20) support functional registration, according to the requirements proposed in § 170.315(j)(1) as well as dynamic registration according to the requirements proposed in § 170.315(j)(2) in § 170.315(g)(20)(i). The capability to support functional registration in § 170.315(g)(20)(i)(A) is the same as those currently in § 170.315(g)(10)(iii) for functional registration, which are required for Health IT Modules certified to § 170.315(g)(10). We additionally propose in § 170.315(g)(20)(i)(B) to require support for dynamic registration according to the certification criterion proposed in § 170.315(j)(2). Dynamic registration of apps is intended to reduce the burden of application registration through automated processes. Please see the section titled “New Requirements to Support Dynamic Client Registration Protocol in the Program” for more details about our dynamic registration proposal (see section III.B.15).</P>
                    <P>We also propose that Health IT Modules certified to § 170.315(g)(20) support authentication and authorization capabilities to support public health data access to provider systems. We propose to require such capabilities in § 170.315(g)(20)(ii). Specifically, we propose in § 170.315(g)(20)(ii)(A) to require support for SMART Backend Services system authentication and authorization according to the proposed certification criterion in § 170.315(j)(7) for system applications functionally registered according to the capabilities in § 170.315(g)(20)(i)(A). These capabilities are the same as those currently in § 170.315(g)(10)(v) and (vii) which are required for Health IT Modules certified to § 170.315(g)(10). Furthermore, we propose in § 170.315(g)(20)(ii)(B) to require support for asymmetric certificate-based system authentication and authorization according to the requirements proposed in § 170.315(j)(8) for system apps dynamically registered using the capabilities in § 170.315(g)(20)(i)(B). These requirements would support authentication and authorization for dynamically registered system apps. The proposed requirements to support system authentication and authorization for functionally and dynamically registered system apps will ensure that Health IT Modules certified to § 170.315(g)(20) criterion support authorization server capabilities to enable public health authorization to provider servers.</P>
                    <P>
                        In § 170.315(g)(20)(iii), we propose a set of requirements necessary to facilitate PHA access to provider system data. These include identification of specific HL7 FHIR Resources often needed by PHAs, capabilities to read and search these data, and support for the subscription of event-based topics that PHAs can leverage in the development of IGs for various public health reporting use cases. We propose that Health IT Modules certified to § 170.315(g)(20) support read and search capabilities for each HL7 FHIR Resource identified in § 170.315(g)(20)(iii)(A) according to the standards and implementation specifications adopted in § 170.215(b)(2). This would enable an API User to read and search patient data that are profiled according to the USPHPL IG in § 170.215(b)(2), including the following HL7 FHIR Resources: Condition; Encounter; Location; Observation; Organization; Patient; and PractionerRole, identified in § 170.315(g)(20)(iii)(A)(
                        <E T="03">1</E>
                        )-(
                        <E T="03">7</E>
                        ).
                    </P>
                    <P>In referencing the USPHPL IG in § 170.215(b)(2), our intention is to leverage a public health-specific data set of common data elements necessary to support core public health exchange use cases. The USPHPL IG contains reusable content profiles that represent common data PHAs and public health officials receive and use. It was created as a complement to the US Core IG—the USPHPL IG re-uses US Core profiles whenever possible, and only adds new profiles when there is a need for specific profiles for public health data exchange, and no corresponding profile in US Core IG. We believe the USPHPL IG would enable the exchange of health data from healthcare organizations to PHAs with minimal implementation burden, due to its foundation in the US Core IG, and through the reuse of common profiles for public health data exchange purposes. We welcome comment on these proposed information access requirements described in 170.315(g)(20)(iii)(A).</P>
                    <P>
                        In § 170.315(g)(20)(iii)(B) we propose that Health IT Modules support read and search API calls and bulk FHIR API calls. Specifically, in § 170.315(g)(20)(iii)(B)(
                        <E T="03">1</E>
                        )(
                        <E T="03">i</E>
                        ) we propose that Health IT Modules support the ability for a system client to read HL7 FHIR Resources using the “id” data element for the data elements identified in § 170.315(g)(20)(iii)(A), and return the Resources profiled according to the USPHPL IG in § 170.215(b)(2). Similarly, we propose that Health IT Modules support the ability for a system client to search HL7 FHIR Resources according to the applicable search requirements in the “US Core Server CapabilityStatement” for the Resources included in § 170.315(g)(20)(iii)(A) and return the information profiled according to the implementation specification in § 170.215(b)(2). Together, these requirements would enable public health systems to extract data from provider systems, consistent with scopes and interactions identified in the SMART App Launch IGs in § 170.215(c). Once those data are read by the API call, the receiving system is then able to parse, process, and update receiving systems. Through this standards-based approach, Health IT Modules certified to § 170.315(g)(20) would enable consistent and predictable access to health data from which apps, systems, and other public health services can be informed and developed.
                    </P>
                    <P>
                        Additionally, in § 170.315(g)(20)(ii)(
                        <E T="03">2</E>
                        ), we propose that the Health IT Module certified to 
                        <PRTPAGE P="63561"/>
                        § 170.315(g)(20) must support Bulk FHIR queries by responding to requests for data according to the implementation specifications adopted in § 170.215(a) and at least one of the versions of the implementation specifications adopted in § 170.215(d) for the Resources listed in § 170.315(g)(20)(iii)(A) and return the information profiled according to the USPHL IG proposed in § 170.215(b)(2). We also propose in § 170.315(g)(20)(ii)(
                        <E T="03">2</E>
                        ) that for the time period up to and including December 31, 2027, the Health IT Module must support either the “GroupLevelExport” operation or the “_type” query parameter of at least one of the versions of the implementation specifications adopted in § 170.215(d), or a Health IT Module may support both the “GroupLevelExport” operation and the “_type” query parameter of at least one of the versions of the implementation specifications adopted in § 170.215(d). On and after January 1, 2028, a Health IT Module certified to § 170.315(g)(20) must meet both the “GroupLevelExport” operation and the “_type” query parameter for each of the data included in § 170.315(g)(20)(iii)(A) according to at least one of the versions of the implementation specifications adopted in § 170.215(d).
                    </P>
                    <P>We welcome comment on our proposals for public health information access and our proposals to require support of HL7 FHIR Profiles as specified in the USPHPL IG as the foundation for Health IT Modules certified to § 170.315(g)(20). We recognize that the USPHPL IG does not support all data elements referenced in implementation specifications that support public health use cases represented by the current certification criteria in § 170.315(f). Nor does the USPHPL IG include all data elements necessary for proposed public health reporting in § 170.315(f). We understand this gap, and we intend to support updates to the USPHPL IG through current HL7 activities and processes, future edits, additions, and updates to the HL7 FHIR profiles contained within the USPHPL IG. For example, we anticipate that future versions of the USPHPL IG could include additional use case-specific data elements that are identified in USCDI+ Public Health.</P>
                    <HD SOURCE="HD3">iii. Incorporation and References to Criteria in § 170.315(j) as Part of the Standardized API for Public Health Data Exchange</HD>
                    <P>
                        As stated previously, we propose that Health IT Modules certified to § 170.315(g)(20) include modular capabilities and foundational standards to support a transition to HL7 FHIR-based public health data exchange. As described in section III.B.16 of this proposed rule, we describe a new category of “modular API capabilities” certification criteria in § 170.315(j). Specifically, in § 170.315(g)(20)(iii)(C) we propose that a Health IT Module certified to § 170.315(g)(20) support subscriptions according to the requirements in § 170.315(j)(23), including support for a client to subscribe to notifications and then send notifications for event-based interactions. In addition to the support for the framework, subscription topics, and filters in § 170.315(j)(23), we propose in § 170.315(g)(20)(iii)(C)(
                        <E T="03">1</E>
                        ) that a Health IT Module certified to § 170.315(g)(20) enable a client to subscribe to notifications filtered according to the conditions “Encounter.reasonCode,” and “Encounter.subject” when a patient encounter starts and the conditions “Encounter.reasonCode,” and “Encounter.subject” when a patient encounter ends. When an encounter starts or ends, we propose that Health IT Modules certified to § 170.315(g)(20) can send notifications for the event-based interactions identified in § 170.315(g)(20)(iii)(C)(
                        <E T="03">1</E>
                        )(
                        <E T="03">i</E>
                        ) and (
                        <E T="03">ii</E>
                        ) according to the standard in § 170.215(a) and implementation specification in § 170.215(h)(1). Taken together, we believe that these capabilities would ensure that PHAs will have consistent access of discrete functionalities, defined capabilities, and standardized data from providers using certified health IT systems for a range of public health use cases. We welcome comment on these proposals.
                    </P>
                    <P>We also invite comment on whether there is utility in requiring future support of other emerging HL7 FHIR standards, such as CDS Hooks proposed as “workflow triggers for decision support interventions—services” in § 170.315(j)(23) as part of the certification criterion in § 170.315(g)(20), to support public health data exchange use cases.</P>
                    <HD SOURCE="HD3">14. Bulk Data Enhancements</HD>
                    <HD SOURCE="HD3">a. Background</HD>
                    <P>
                        In the ONC Cures Act Final Rule, we adopted the HL7® FHIR® Bulk Data Access (Flat FHIR) (v1.0.0: STU 1) implementation specification (referred to as the Bulk v1 IG), including mandatory support for the “group-export” “OperationDefinition,” in § 170.215(a)(4) to enable consistent implementation of API-enabled “read” services for multiple patients (85 FR 25742). In the HTI-1 Final Rule we moved this Bulk v1 IG standard to § 170.215(d)(1) (89 FR 1283). The Bulk v1 IG builds off the FHIR Asynchronous Pattern to define a standardized process for authenticated and authorized clients to “request a Bulk Data Export from a server, receive status information regarding progress in the generation of the requested files, and retrieve these files.” 
                        <SU>160</SU>
                        <FTREF/>
                         The widespread adoption of Bulk Data APIs enables automated communication between health systems to support use cases like public health surveillance and reporting, clinical research, data analytics, electronic clinical quality measure reporting and more.
                    </P>
                    <FTNT>
                        <P>
                            <SU>160</SU>
                             
                            <E T="03">https://hl7.org/fhir/uv/bulkdata/export.html#bulk-data-export-operation-request-flow</E>
                            .
                        </P>
                    </FTNT>
                    <P>Support for the “group-export” “OperationDefinition” operation enables “application developers interacting with § 170.315(g)(10)-certified Health IT Modules to export the complete set of FHIR resources . . . for a pre-defined cohort of patients” (85 FR 25742). As we have stated previously, these cohorts are “defined at the discretion of the user . . . including, for example, a group of patients that meet certain disease criteria or fall under a certain insurance plan” (85 FR 25742, 25743). We have also noted previously that the Bulk v1 IG “has optional parameters which can be used to filter results to a period of time, or one or several specified FHIR resources” (85 FR 25744).</P>
                    <HD SOURCE="HD3">b. Proposal</HD>
                    <P>We propose to adopt the HL7 FHIR Bulk Data Access (v2.0.0: STU 2) implementation specification (Bulk v2 IG) in § 170.215(d)(2) and incorporate it by reference as a subparagraph in § 170.299. Additionally, we propose that the adoption of the Bulk v1 IG in § 170.215(d)(1) would expire on January 1, 2028. We clarify that both the Bulk v1 IG and Bulk v2 IG would be available for purposes of certification where certification criteria reference the implementation specification in § 170.215(d) until the Bulk v1 IG adoption expiration date of January 1, 2028, after which time only the Bulk v2 IG would be available for certification, if we finalize our rule as proposed.</P>
                    <P>
                        We believe that raising the floor for certification of bulk data export capabilities would help enable performant and consistent population service APIs. The Bulk v2 IG includes additional clarifications and expanded definitions based on industry feedback related to implementation of the Bulk v1 IG and HL7 workgroup consensus. We 
                        <PRTPAGE P="63562"/>
                        believe adopting the Bulk v2 IG would not add significant burden for Certified API Developers with Health IT Modules certified to certification criteria that reference the implementation specification in § 170.215(d) who have already implemented the Bulk v1 IG. The new requirements included in the Bulk v2 IG are generally incremental updates to Bulk v1 IG requirements, and only a handful of the updates are in scope for testing and certification.
                        <SU>161</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>161</SU>
                             We already include testing support for the Bulk v2 IG, since it was included as a 2022 Approved Standard via the Standards Version Advancement Process (SVAP), and in the Inferno testing tool we only needed three new tests for testing the Bulk v2 IG in comparison to the Bulk v1 IG.
                        </P>
                    </FTNT>
                    <P>
                        One of the pertinent new requirements in the Bulk v2 IG is required server support for the “_since” parameter, which allows for filtering by date and time on bulk exports. This parameter can be used to help improve API performance by reducing total resources exported and overall export time. This parameter is also defined in the Bulk v1 IG, but it is marked as “optional” for server support there. The Bulk v2 IG contains added clarifications and expanded definitions for the “_since” parameter, and the parameter is marked as “required” for server (
                        <E T="03">i.e.,</E>
                         Health IT Module) support in the Bulk v2 IG.
                    </P>
                    <P>The added requirement for the “_since” parameter, along with all the other clarifications and expanded definitions across the whole Bulk v2 IG, are aspects that we believe will help provide consistent implementation guidance and thus improve access, exchange, and use of EHI because developers will have more guidance to refer to when implementing their Bulk Data APIs. We welcome comment on our proposal to adopt the HL7 FHIR Bulk Data Access (v2.0.0: STU 2) implementation specification.</P>
                    <P>Our proposal to adopt the Bulk v2 IG in § 170.215(d)(2) implicates all certification criteria that reference the implementation specification in § 170.215(d), and in this proposed rule these certification criteria are: § 170.315(f)(23), (f)(25), (g)(10), (g)(20), (g)(31), (g)(32), and (g)(33). Note that § 170.315(f)(23), (f)(25), (g)(20), (g)(31), (g)(32), and (g)(33) are new Program certification criteria proposed in this rule, and the only currently finalized certification criterion in the Program that includes reference to § 170.215(d) is § 170.315(g)(10).</P>
                    <P>We propose to continue requiring mandatory support for the “group-export” “OperationDefinition” defined in the Bulk v2 IG for certification to § 170.315(g)(10); and we propose to require support for the “group-export” “OperationDefinition” in our proposed new certification criteria in § 170.315(g)(20), (31), (32), and (33). We refer readers to sections III.B.13.f and III.B.20.c for additional discussion on our proposed new certification criteria in § 170.315(g)(20), (31), (32), and (33) and proposed Bulk IG requirements.</P>
                    <P>
                        We additionally propose to require support for the Bulk v2 IG “optional” query parameter known as “_type” for testing and certification to § 170.315(g)(10), (20), (31), (32), and (33) because we believe that implementation of the “_type” parameter will meaningfully improve API performance by reducing total resources exported and overall export time. The “_type” filter allows a requesting system to provide a list of FHIR resource types for the responding system to use, which limits the resources returned to a specific subset. Like the “_since” parameter, we believe that this requirement to use “_type” parameter is an incremental step that will encourage further industry adoption. As of Spring 2023, 73.7% of deployed Bulk FHIR certified Health IT Modules already support this optional parameter.
                        <SU>162</SU>
                        <FTREF/>
                         We welcome comment on our proposal to require support for the “_type” parameter for certification.
                    </P>
                    <FTNT>
                        <P>
                            <SU>162</SU>
                             Market share numbers come from this briefing: 
                            <E T="03">https://www.hhs.gov/sites/default/files/2022-02-17-1300-emr-in-healthcare-tlpwhite.pdf.</E>
                             Support for this parameter was gathered by reviewing developer documentation.
                        </P>
                    </FTNT>
                    <P>
                        Finally, we welcome comment on the issues hindering the effective exchange of population data using Bulk FHIR APIs and additional steps ONC can take to help address those issues. Our research and findings to date, on the use of deployed ONC-certified Bulk FHIR APIs, indicate that there are significant challenges and barriers hindering interoperability. We have consistently heard about challenges creating the groups necessary for invoking the “group-export” operation, including that there is not a standard process for creating groups and that group sizes are being limited. We have also heard about significant performance issues, with Bulk FHIR exports in some cases taking days or even weeks to complete.
                        <SU>163</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>163</SU>
                             Jones, James R., et al. “Real World Performance of the 21st Century Cures Act Population Level Application Programming Interface.” 
                            <E T="03">medRxiv</E>
                             (2023): 2023-10. 
                            <E T="03">https://www.medrxiv.org/content/10.1101/2023.10.05.23296560v2</E>
                            .
                        </P>
                    </FTNT>
                    <P>
                        For currently certified Bulk FHIR APIs, we expect that § 170.315(g)(10) certified Health IT Modules support complete patient cohorts (
                        <E T="03">i.e.,</E>
                         groups) that enable automated communication between health systems without needing to parse data across multiple exports. For future rulemaking, we are interested in considering testable minimum expectations and/or thresholds for certified Bulk FHIR API performance. We acknowledge that there is variability in Bulk FHIR group exports and performance based on things like system architectures and the variability of resources per patient in a patient cohort. We seek input on Bulk FHIR API performance experiences from users in the field and seek comment on any potential performance bases, expectations, thresholds, industry standards, etc. that we could consider in the future for Certified Bulk FHIR APIs as a baseline. We also welcome comment on the latest developments in the Bulk FHIR space, like the early-stage proposals for Bulk FHIR import functionality that are intended to address data “push” use cases as opposed to the data “pull” flow modeled by Bulk FHIR export.
                        <SU>164</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>164</SU>
                             FHIR Bulk Data Import early stage proposals can be found here: 
                            <E T="03">https://github.com/smart-on-fhir/bulk-import/blob/master/import.md</E>
                            .
                        </P>
                    </FTNT>
                    <P>We welcome comment on experiences using Bulk FHIR APIs deployed in Health IT Modules certified to § 170.315(g)(10)(i)(B) and (ii)(B) (note that elsewhere in this proposed rule we are proposing to restructure § 170.315(g)(10) and move the Bulk FHIR API requirements in § 170.315(g)(10) to § 170.315(g)(10)(iii)). We also welcome comment on performance experiences and minimum expectations for future iterations of our Bulk FHIR API requirements for different use cases, insofar as we should be thinking about performance differently for different use cases.</P>
                    <HD SOURCE="HD3">15. New Requirements To Support Dynamic Client Registration Protocol In the Program</HD>
                    <HD SOURCE="HD3">a. Background to Dynamic Client Registration</HD>
                    <P>
                        In the ONC Cures Act Proposed Rule's preamble (84 FR 7483) we discussed that we considered proposing to require the OAuth 2.0 Dynamic Client Registration Protocol (DCRP) as per RFC 7591 
                        <SU>165</SU>
                        <FTREF/>
                         as the mechanism for application registration in the proposed § 170.315(g)(10)(iii). However, in the ONC Cures Act Final Rule (85 FR 25745), we noted that DCRP had low industry adoption at the time, and we subsequently finalized the application registration requirement in § 170.315(g)(10)(iii) without the DCRP 
                        <PRTPAGE P="63563"/>
                        standard. We also encouraged health IT developers to coalesce around the development of a common industry standard for application registration.
                    </P>
                    <FTNT>
                        <P>
                            <SU>165</SU>
                             
                            <E T="03">See</E>
                             RFC 7591—OAuth 2.0 Dynamic Client Registration Protocol. Available at: 
                            <E T="03">https://datatracker.ietf.org/doc/html/rfc7591</E>
                            .
                        </P>
                    </FTNT>
                    <P>In addition, we also finalized in the ONC Cures Act Final Rule the API Maintenance of Certification requirement of authenticity verification and registration for production use in § 170.404(b)(1) (85 FR 25763 through 25764). This requirement permits a Certified API Developer to implement an objective and uniform process to verify the authenticity of API Users, where “API Users” is defined at 45 CFR 170.404(c) and complete this process within ten business days. We also finalized in § 170.404(b)(1)(ii) that the Certified API Developer must register and enable all applications for production use within five business days of completing its verification of an API User's authenticity.</P>
                    <P>In the years since finalization of requirements in § 170.315(g)(10)(iii) and § 170.404(b)(1) in the ONC Cures Act Final Rule, ONC has received feedback that the non-standard application registration process can be burdensome to API Users. The manual nature of some registration processes does not enable efficient registration across multiple certified Health IT Module deployments, and the absence of standardized requirements may cause varying, disparate registration processes across certified Health IT Modules, making widespread registration burdensome. To reduce the registration burden for API Users, we propose to adopt a standard for application registration in § 170.215(o)(1) and adopt a new certification criterion in § 170.315(j)(2) for dynamic registration as part of the suite of revised and new certification criteria proposed as modular API capabilities (See section III.B.16).</P>
                    <P>Consistent with our proposed new approach to leverage modular API capabilities in § 170.315(j) across various API-related certification criteria, we propose to revise the certification criterion in § 170.315(g)(10) by referencing § 170.315(j)(2) and requiring support for a dynamic registration pathway. We propose to revise the API Maintenance of Certification requirements in § 170.404(b) to require support for publication of information necessary to dynamically register apps. Additionally, we propose to adopt the standard for dynamic application registration as part of the certification criteria in § 170.315(g)(20), (30), (32)-(35). (Please see section III.B.13.d for details on the § 170.315(g)(20) Standardized API for public health data exchange certification criterion proposal and section III.B.20.c for details on our Patient, Provider, and Payer APIs § 170.315(g)(30), (32)-(35) proposals).</P>
                    <HD SOURCE="HD3">b. Adoption of HL7 UDAP Security IG v1</HD>
                    <P>The OAuth 2.0 framework enables a third-party application to obtain limited access to a Hypertext Transfer Protocol (HTTP) service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. Given that the § 170.315(g)(10) certification criterion's authorization model is based on the OAuthAuthorization Framework, registration is required before an app can access information via an API conformant to the § 170.315(g)(10) certification criterion. A § 170.315(g)(10) certified Health IT Module's authorization server must support app registration, as required per the current requirements in § 170.315(g)(10)(iii).</P>
                    <P>
                        To standardize the application registration approach in Program API criteria, we propose to adopt the HL7® Unified Data Access Profiles (UDAP
                        <E T="51">TM</E>
                        ) Security for Scalable Registration, Authentication, and Authorization Implementation Guide Release 1.0.0 (UDAP Security IG v1) in § 170.215(o)(1). The UDAP Security IG v1 enables dynamic registration in alignment with the OAuth 2.0 security paradigm already in use in the Program. The SMART App Launch IG, which profiles the OAuthAuthorization Framework established in RFC 6749, is currently required in the Program in the § 170.315(g)(10) certification criterion to enable secure authorization of apps to receive a single patient's data via FHIR. Additionally, the SMART Backend Services specification, also profiling OAuth 2.0, already required in the Program in the § 170.315(g)(10) certification criterion for authorization to retrieve multiple patient's data. The UDAP Security IG v1 would augment the existing OAuth 2.0 found in the Program by enabling scalable and standardized application registration capabilities compatible with FHIR and the SMART App Launch IG to be referenced as requirements in Program API criteria. While the UDAP Security IG v1 defines additional capabilities beyond dynamic registration, Program API criteria requirements proposed in this rule focus on dynamic registration and subsequent authorization requests of dynamically registered apps. To achieve this focus, the Program API proposals referencing the UDAP Security IG v1 require only specific sections relevant to those capabilities.
                    </P>
                    <P>Scalable dynamic registration in the UDAP Security IG v1 relies upon “trust communities.” Trust communities enable scalable trust by establishing common policies that all participants agree to abide by, thereby forgoing the need for individual agreements between organizations for establishing trusted relationships. Participation in a trust community can be represented in a secure and trustworthy manner in the form of cryptographically secure digital certificates. These certificates enable an application to prove to a server that it and its developer are trusted to meet the expectations of the trust community. With the certificate as proof of the trustworthiness of an API User and their application, registration can proceed in an automated manner without the need to perform manual or non-standardized trust verification.</P>
                    <P>We note that for the purposes of our proposals in § 170.315(g)(10), (20), (30), (32)-(35), and § 170.404(b)(1) an API User and the certified API technology that an API Information Source uses must be part of the same trust community for dynamic registration to occur according to the UDAP Security IG v1. Depending on the scenario, Certified API Developers as well as API Information Sources would be best positioned to determine which trust communities are supported for dynamic registration at a specific deployment. Under this proposal to adopt the UDAP Security IG v1, we have not proposed to require that all trust communities be supported by a Certified API Developer, nor have we specified a particular trust community. However, if an API User seeks to connect an application that is part of the same trust community as the deployed certified API technology, then dynamic registration must be made available to the API User's application.</P>
                    <P>
                        We are aware that there is a planned update to UDAP Security IG v1, UDAP Security IG v1.0.1, that may publish after the publication of this proposed rule. We anticipate that UDAP Security IG v1.0.1 will fix errors within the UDAP Security IG v1 and not include substantial revisions. As an alternative proposal to adopting the UDAP Security IG v1 in § 170.215(o)(1), we propose to adopt UDAP Security IG v1.0.1 in § 170.215(o)(1) if it is published prior to publication of a final rule finalizing policies proposed in this proposed rule. Interested parties may review the current version of the UDAP Security IG v1.0.1 at 
                        <E T="03">https://build.fhir.org/ig/HL7/fhir-udap-security-ig/.</E>
                        <PRTPAGE P="63564"/>
                    </P>
                    <HD SOURCE="HD3">c. Revision of Standardized API for Patient and Population Services To Support Dynamic Client Registration</HD>
                    <P>To reduce API User burden when registering their applications and facilitate accessibility of patient health data, we propose to revise the § 170.315(g)(10) certification criterion to require on and after January 1, 2028, dynamic registration of confidential apps, including patient-facing, user-facing, and system apps, and subsequent authorization and authentication support for such dynamically registered apps. We note for this proposal that “user” is as defined in 77 FR 54168. First, we propose to modify the existing registration requirements currently in § 170.315(g)(10)(iii) to require a standardized dynamic registration pathway supporting patient-facing, user-facing, and system confidential apps according to the UDAP Security IG v1. As proposed in section III.B.19 of this rule, the registration requirements for the § 170.315(g)(10) certification criterion are proposed to be organized under § 170.315(g)(10)(i). Therefore, we propose this new requirement for a dynamic registration pathway in § 170.315(g)(10)(i)(B). This new standardized dynamic registration pathway would exist alongside the functional registration pathway currently required in § 170.315(g)(10)(iii) and proposed in this rule to be included in § 170.315(g)(10)(i)(A). Second, we propose to require support for authentication and authorization for dynamically registered patient-facing, user-facing, and system confidential apps. Please see section III.B.19 for further details on the proposed re-structuring of the § 170.315(g)(10) certification criterion.</P>
                    <P>
                        As described in the “Revised Standardized API for Patient and Population Services Criterion to Align with Modular API Capabilities” section of this rule, we propose to restructure and move to § 170.315(g)(10)(ii)(A) the existing requirements in § 170.315(g)(10)(v)(A) for authorization for functionally registered patient-facing apps and user-facing apps according to the SMART App Launch IG. In section III.B.19, we propose moving the authorization requirements for functionally registered patient-facing apps to the proposed § 170.315(g)(10)(ii)(A)(
                        <E T="03">1</E>
                        )(
                        <E T="03">i</E>
                        ) and functionally registered user-facing apps to the proposed § 170.315(g)(10)(ii)(A)(
                        <E T="03">2</E>
                        )(
                        <E T="03">i</E>
                        ). We refer readers to section III.B.19 of this proposed rule for additional details regarding this and other related proposals. As described in more detail in subsequent paragraphs, we propose to require support for authorization for dynamically registered patient-facing apps in accordance with the requirements at the proposed § 170.315(g)(10)(ii)(A)(
                        <E T="03">1</E>
                        )(
                        <E T="03">i</E>
                        ) and for dynamically registered user-facing apps in accordance with the requirements at the proposed § 170.315(g)(10)(ii)(A)(
                        <E T="03">2</E>
                        )(
                        <E T="03">i</E>
                        ).
                    </P>
                    <P>
                        On and after January 1, 2028, we propose to require support for authentication in accordance with the UDAP Security IG v1 of dynamically registered patient-facing apps in accordance with the requirements at the proposed § 170.315(g)(10)(ii)(A)(
                        <E T="03">1</E>
                        )(
                        <E T="03">ii</E>
                        ) and for dynamically registered user-facing apps in accordance with the requirements proposed in § 170.315(g)(10)(ii)(A)(
                        <E T="03">2</E>
                        )(
                        <E T="03">ii</E>
                        ). We describe the details of these proposed authentication requirements in subsequent paragraphs.
                    </P>
                    <P>
                        On and after January 1, 2028, we propose to require support for authentication and authorization in accordance with the UDAP Security IG v1 of dynamically registered system apps in accordance with the requirements at the proposed § 170.315(g)(10)(iii)(A)(
                        <E T="03">2</E>
                        ). We describe the details of these proposed authentication and authorization requirements in subsequent paragraphs. These proposed authorization requirements would establish a consistent, standardized method for authorizing dynamically registered patient-facing, user-facing, and system apps to retrieve patient data.
                    </P>
                    <P>We propose in § 170.315(g)(10)(i)(B) to require on and after January 1, 2028, support for a dynamic registration pathway in the § 170.315(g)(10) certification criterion for confidential apps, including patient-facing, user-facing, and system apps, standardized according to the UDAP Security IG v1. Using this proposed pathway, patient-facing, user-facing, and system confidential apps capable of supporting the UDAP Security IG v1 would be able to dynamically register with the Health IT Module's authorization server in an automated manner. Apps incapable of dynamic registration according to UDAP Security IG v1 would still be able to be registered using the current functional, non-standardized registration pathway currently specified in § 170.315(g)(10)(iii), which is proposed to be moved to § 170.315(g)(10)(i)(A) according to the proposal in section III.B.19 of this rule. We propose in § 170.315(g)(10)(i)(B) to require Health IT Modules certified to § 170.315(g)(10) to support dynamic registration of confidential apps according to the requirements in § 170.315(j)(2), which requires support for dynamic registration of confidential apps according to the UDAP Security IG v1 proposed in § 170.215(o). This includes mandatory support for sections “Home,” “Discovery,” and “Registration” as well as the “community” query parameter as defined in section “Multiple Trust Communities.” We propose requiring mandatory support for the aforementioned sections as they are the sections from the UDAP Security IG v1 relevant to supporting dynamic registration. We note that trust communities are responsible for enforcing their own policies regarding security and trust, and we encourage such communities to address the topics mentioned in section “Trust Community Checklist” of the UDAP Security IG v1 in order to further support for dynamic registration processes.</P>
                    <P>We clarify in this proposal that Health IT Modules certified to § 170.315(g)(10), through reference to § 170.315(j)(2) in § 170.315(g)(10)(i)(B), must support the otherwise optional “community” query parameter as defined in section “Multiple Trust Communities” of the UDAP Security IG v1 to facilitate an app's ability to retrieve dynamic registration metadata particular to a specific trust community. The “community” query parameter enables an application to receive metadata integral to the dynamic registration process which may otherwise be obscured if the Health IT Module certified to § 170.315(g)(10) supports multiple trust communities.</P>
                    <P>
                        Next, we propose to require on and after January 1, 2028, support for client authentication for dynamically registered patient-facing confidential apps according to section “Consumer-Facing” of the UDAP Security IG v1 in § 170.315(g)(10)(ii)(A)(
                        <E T="03">1</E>
                        )(
                        <E T="03">ii</E>
                        ) by referencing the proposed certification criterion in § 170.315(j)(5). The proposed certification criterion in § 170.315(j)(5), in turn, requires support for authentication as detailed in section “Consumer-Facing” of the UDAP Security IG v1 proposed in § 170.215(o). It is through this series of cross-references that we propose, in § 170.315(g)(10)(ii)(A)(
                        <E T="03">1</E>
                        )(
                        <E T="03">ii</E>
                        ), to require support for client authentication for dynamically registered patient-facing confidential apps according to section “Consumer-Facing” of the UDAP Security IG v1.
                    </P>
                    <P>
                        Further, we propose to require on and after January 1, 2028, support for client authentication for dynamically 
                        <PRTPAGE P="63565"/>
                        registered user-facing confidential apps according to the “Business-to-Business” section of the UDAP Security IG v1 in § 170.315(g)(10)(ii)(A)(
                        <E T="03">2</E>
                        )(
                        <E T="03">ii</E>
                        ) by referencing the proposed certification criterion in § 170.315(j)(11). The proposed certification criterion in § 170.315(j)(11), in turn, requires support for authentication for the “authorization_code” grant type as detailed in section “Business-to-Business” of the UDAP Security IG v1 proposed in § 170.215(o). It is through this series of cross-references that we propose, in § 170.315(g)(10)(ii)(A)(
                        <E T="03">2</E>
                        )(
                        <E T="03">ii</E>
                        ), to require support for client authentication for dynamically registered user-facing confidential apps according to section “Business-to-Business” of the UDAP Security IG v1.
                    </P>
                    <P>
                        We propose requiring the “Consumer Facing” and “Business-to-Business” sections of the UDAP Security IG v1 as they provide authentication requirements for dynamically registered patient-facing apps and user-facing apps respectively during the authorization process. The conformance expectation for support for patient-facing apps for this proposal is that the SMART App Launch capabilities, required in § 170.315(g)(10)(ii)(A)(
                        <E T="03">1</E>
                        )(
                        <E T="03">i</E>
                        ) by referencing the certification criterion proposed in § 170.315(j)(9), would be required to be supported for both functionally registered and dynamically registered patient-facing apps. We propose the exception that client authentication for dynamically registered apps would be required to be supported according to section “Consumer-Facing” of the UDAP Security IG v1 as proposed in § 170.315(g)(10)(ii)(A)(
                        <E T="03">1</E>
                        )(
                        <E T="03">ii</E>
                        ) instead of client authentication according to the SMART App Launch implementation guide.
                    </P>
                    <P>
                        Similarly, the requirement for support for user-facing apps for this proposal is that both functionally and dynamically registered user-facing apps would be required to be supported according to the SMART App Launch capabilities required in § 170.315(g)(10)(ii)(A)(
                        <E T="03">2</E>
                        )(
                        <E T="03">i</E>
                        ) by referencing § 170.315(j)(10)(i). However, client authentication for dynamically registered user-facing applications would be required to be supported according to the “Business-to-Business” section of the UDAP Security IG v1 as proposed in § 170.315(g)(10)(ii)(A)(
                        <E T="03">2</E>
                        )(
                        <E T="03">ii</E>
                        ) instead of the SMART App Launch implementation guide.
                    </P>
                    <P>
                        This proposal does not propose to change the authentication and authorization requirements for patient-facing apps and user-facing apps registered using the functional registration pathway proposed in § 170.315(g)(10)(i)(A). Authentication and authorization for functionally registered patient-facing apps would be expected to occur according to the requirements proposed in § 170.315(g)(10)(ii)(A)(
                        <E T="03">1</E>
                        )(
                        <E T="03">i</E>
                        ), which would by reference to the proposed § 170.315(j)(5) require SMART App Launch capabilities relevant to patient-facing app authentication and authorization. Similarly, authentication and authorization for functionally registered user-facing apps would be expected to occur according to the requirements proposed in § 170.315(g)(10)(ii)(A)(
                        <E T="03">2</E>
                        )(
                        <E T="03">i</E>
                        ), which would by reference to § 170.315(j)(10)(i) require SMART App Launch capabilities relevant to user-facing app authentication and authorization. We refer readers to the “Revised Standardized API for Patient and Population Services Criterion to Align with Modular API Capabilities” section of this rule for additional information about the proposed requirements in § 170.315(g)(10)(ii)(A)(
                        <E T="03">1</E>
                        )(
                        <E T="03">i</E>
                        ) and (
                        <E T="03">2</E>
                        )(
                        <E T="03">i</E>
                        ) and how those proposed requirements relate to current § 170.315(g)(10) requirements for authentication and authorization for functionally registered patient-facing apps and user-facing apps.
                    </P>
                    <P>
                        We also propose in § 170.315(g)(10)(iii)(A)(
                        <E T="03">2</E>
                        ) that on and after January 1, 2028, authentication and authorization for dynamically registered system confidential apps must be supported according to the “Business-to-Business” section of the UDAP Security IG v1 by referencing the proposed § 170.315(j)(8). Proposed § 170.315(j)(8) would require authentication and authorization for the “client_credentials” grant type according to the “Business-to-Business” section of the UDAP Security IG v1 proposed in § 170.215(o). We propose the system authentication and authorization requirements in § 170.315(g)(10)(iii)(A)(
                        <E T="03">2</E>
                        ) to require support for a system authorization process which provides client authentication consistent with the proposed dynamic registration process for system confidential apps.
                    </P>
                    <P>
                        This proposal does not propose to change the authentication and authorization requirements for system apps registered using the functional registration pathway proposed in § 170.315(g)(10)(i)(A). Authentication and authorization for functionally registered system apps would be expected to occur according to the requirements proposed in § 170.315(g)(10)(iii)(A)(
                        <E T="03">1</E>
                        ), which would by reference to proposed § 170.315(j)(7) require the “Backend Services” section of at least one implementation specification adopted in § 170.215(c). We refer readers to the “Revised Standardized API for Patient and Population Services Criterion to Align with Modular API Capabilities” section of this rule for additional information about the proposed requirements in § 170.315(g)(10)(iii)(A)(
                        <E T="03">1</E>
                        ) and how those proposed requirements relate to current § 170.315(g)(10) requirements for authentication and authorization for functionally registered system apps.
                    </P>
                    <P>We note that we propose in sections III.B.13.d and III.B.20.c to adopt dynamic registration according to the UDAP Security IG v1 for Health IT Modules certified to § 170.315(g)(20), (30), (32)-(35). We invite readers to review those sections for details related to those proposals.</P>
                    <HD SOURCE="HD3">d. Removal of Reference to OpenID Connect Core Specification</HD>
                    <P>
                        In the ONC Cures Act Final Rule, we adopted the OpenID Connect Core 1.0 specification in § 170.215(b) and clarified that only the components included in the SMART App Launch Framework 1.0.0 Implementation Guide adopted in § 170.215(a)(3) were in scope for testing and certification (85 FR 25742). Relatedly, we finalized requirements for the § 170.315(g)(10) certification criterion in (g)(10)(v)(A)(
                        <E T="03">1</E>
                        )(
                        <E T="03">i</E>
                        ) that required for first time connections that authentication and authorization must occur during the process of granting access to patient data in accordance with SMART App Launch Framework 1.0.0 and OpenID Connect Core 1.0 (85 FR 25746). Subsequently in the HTI-1 Final Rule, we finalized moving the regulatory reference of the OpenID Connect Core 1.0 standard from § 170.215(b) to § 170.215(e)(1) (89 FR 1283).
                    </P>
                    <P>
                        We no longer believe it is necessary to reference the OpenID Connect Core 1.0 specification separately in the API criteria requirements in the Program since the relevant end-user authentication requirements are sufficiently described through the “sso-openid-connect” capability from the versions of the SMART App Launch implementation guide currently and as proposed to be adopted in § 170.215(c). We believe requiring the “sso-openid-connect” capability from the implementation specification in § 170.215(c) is sufficient to specify the intended end-user authentication requirements related to the § 170.315(g)(10), (30), and (34) certification criteria. The “sso-openid-connect” capability is proposed to be required in the § 170.315(g)(10), (30), 
                        <PRTPAGE P="63566"/>
                        and (34) certification criteria by requiring the “Single Sign-on” section from the implementation specifications in § 170.215(c), which is required by referencing the proposed § 170.315(j)(9) certification criterion in (g)(10)(ii)(A)(
                        <E T="03">1</E>
                        )(
                        <E T="03">i</E>
                        ) and (g)(30)(ii)(A) and by referencing the proposed § 170.315(j)(10) certification criterion in (g)(10)(ii)(A)(
                        <E T="03">2</E>
                        )(
                        <E T="03">i</E>
                        ) and (g)(34)(ii)(A)(
                        <E T="03">3</E>
                        )(
                        <E T="03">i</E>
                        ). Additional details regarding the proposed adoption of the “sso-openid-connect” capability in the § 170.315(g)(10) certification criterion is in section III.B.19, and section III.B.20 for the § 170.315(g)(30) and (34) certification criteria.
                    </P>
                    <P>
                        Since we are proposing to adopt the “sso-openid-connect” capability in the § 170.315(g)(10) certification criterion, we propose to remove reference to the § 170.215(e)(1) from the current requirements in § 170.315(g)(10)(v)(A)(
                        <E T="03">1</E>
                        )(
                        <E T="03">i</E>
                        ) (as finalized in HTI-1 Final Rule), which are proposed to be moved to § 170.315(g)(10)(ii)(A)(
                        <E T="03">1</E>
                        )(
                        <E T="03">i</E>
                        ) according to the proposal in section III.B.19 of this rule.
                    </P>
                    <HD SOURCE="HD3">e. API Conditions and Maintenance Updates To Support Dynamic Client Registration</HD>
                    <P>As discussed in the ONC Cures Act Proposed and Final Rules, Section 4002 of the Cures Act requires the Secretary of HHS to establish Conditions and Maintenance of Certification requirements for the Program (84 FR 7465, 85 FR 25647). To implement this, ONC established the Conditions and Maintenance of Certification requirements in the ONC Cures Act Final Rule, including API Conditions and Maintenance requirements in § 170.404, which establish baseline technical and behavioral requirements for Certified API Developers and their certified API technology. The API Conditions and Maintenance requirements established in the ONC Cures Act Final Rule implemented the Cures Act requirement that certified API technology allow “health information from such technology to be accessed, exchanged, and used without special effort through the use of APIs or successor technology or standards, as provided for under applicable law” (85 FR 25647). The API Condition of Certification includes three main conditions that focus on transparency, fees, and openness and pro-competitiveness. To complement these conditions, we also adopted in § 170.404(b) Maintenance of Certification requirements that address ongoing, and, at times, frequent experiences Certified API Developers would face, such as app registration with certified API technology.</P>
                    <P>We propose to revise the app registration-oriented maintenance requirements in § 170.404(b) to align with the proposed registration requirements as part of the certification criteria in § 170.315 (g)(10), (20), (30), and (32)-(35). First, we propose to revise the authenticity verification API Maintenance of Certification requirement in § 170.404(b)(1)(i) to not apply to API Users that are part of a trust community submitting registration requests via the proposed dynamic client registration pathways in the certification criteria in § 170.315 (g)(10), (20), (30), and (32)-(35). Specifically, if the API User is part of a trust community supported by the certified API technology used by an API Information Source and the API User's request to register is conformant to the UDAP Security IG v1, then this Maintenance of Certification requirement shall not apply. We propose to revise the requirement in this manner because API Users that are part of a supported trust community will have already undergone the authenticity verification processes required by the trust community to receive a trust community certificate, and their authenticity for registration can be rapidly proven via verification of their trust community certificate. Therefore, we believe that an additional verification process according to § 170.404(b)(1)(i) by a Certified API Developer for verification of API Users possessing a supported trust community certificate and dynamically registering an app is unnecessary and would hinder dynamic registration of apps at scale.</P>
                    <P>Second, we propose to revise the registration for production use API Maintenance of Certification requirement in § 170.404(b)(1)(ii) so that the registration timeframe for API Users submitting dynamic registration requests according to the UDAP Security IG v1 is one business day, rather than five business days as otherwise applies. Specifically, if the API User is part of a supported trust community and their request to register is valid and conformant to the UDAP Security IG v1, then the Certified API Developer must register and enable the application for production use within one business day. We propose to revise the requirement in this manner to reflect the reduced time necessary to process the automated dynamic registration request.</P>
                    <P>Third, we propose to add a new API Maintenance of Certification requirement by revising paragraph § 170.404(b)(2)(iv) to require a Certified API Developer to publish information regarding the trust communities supported at each service base URL published as part of the requirements in § 170.404(b)(2)(iii) that can be used by patients to access their EHI. This proposal includes publication of the trust community name, contact information, and web address, and identifying URL in a machine-readable format at no charge for each service base URL published in accordance with § 170.404(b)(2)(iii) on and after January 1, 2028. We propose that Health IT Modules certified to § 170.315(g)(10) may, but are not required, to support trust community discovery for dynamic registration in § 170.404(b)(2)(iv) for the period up to and including December 31, 2027. Additionally, we propose in § 170.404(b)(2)(i)(B) that these trust community details be reviewed quarterly, and, as necessary, updated by Certified API Developers. Finally, we propose to change the title of § 170.404(b)(2) to “publication of API discovery details for patient access” to better reflect the requirements we have proposed for this section.</P>
                    <P>We believe that these requirements would better facilitate individuals' access, exchange, and use of EHI, consistent with the Cures Act, and build upon the existing foundations established in the ONC Cures Act Final Rule by leveraging more advanced standards and enable individuals to access, exchange, and use health data without special effort via dynamic registration using applications of their choice. We welcome public comment on if the requirements for publication of API discovery details for § 170.315(g)(10) should include endpoints enabling provider, bulk, and system access to EHI.</P>
                    <P>
                        Publication of information regarding supported trust communities enables API Users to know if a trust community they are participating in is also supported at a certified API technology's endpoint conformant to § 170.315(g)(10) or § 170.315(g)(30), and thus if dynamic client registration is supported at that endpoint for patient-facing apps. Without required publication of supported trust communities, API Users may have to query the metadata for each individual certified API technology's endpoint to confirm if their trust community is supported at that endpoint, which would hinder the registration of apps at scale. This requirement for Certified API Developers to publish trust community information would enable API access, exchange, and use of health data “without special effort” by ensuring API User access to information necessary for 
                        <PRTPAGE P="63567"/>
                        scalable dynamic registration of patient-facing apps with certified API technology certified to § 170.315(g)(10) or § 170.315(g)(30). We refer readers to the ONC Cures Act Proposed Rule (84 FR 7477) for additional discussion regarding why we believe access to trust community, endpoint, and other API discovery details is a necessary attribute to enable API access, exchange, and use of health data “without special effort.”
                    </P>
                    <P>We clarify that Certified API Developers must publish the identifying URI as defined by the trust community, if such a UR is available. Otherwise, Certified API Developers are permitted to establish and publish a unique identifying URI for a trust community. For the purposes of this proposal, trust community URIs defined by the Certified API Developer must be used consistently to uniquely identify a trust community. We welcome comment on our proposal for publication of trust community details in § 170.404(b)(2)(iv).</P>
                    <P>
                        As an alternative to requiring trust community details be published in any machine-readable format at no charge, we seek comment on standards-based publication strategies and formats for the trust community information we propose for § 170.404(b)(2)(iv). We note our proposal earlier in this preamble in section III.B.3 to require service base URLs and related organization details be published in aggregate vendor-consolidate Brand Bundle format according to the User-access Brands and Endpoints (Brands) specification. We seek comment from Certified API Developers on whether they would consider augmenting their Brand Bundle with trust community information. The Brands specification profiles do not specifically account for trust community information, but given the breadth and extensibility of FHIR, the trust community information could theoretically be included in a Brand Bundle in FHIR format (
                        <E T="03">e.g.,</E>
                         using a FHIR extension). If this information is not included in the Brand Bundle, it would need to be published separately in some machine-readable format. We also seek comment from third party-app developers on how this information can best be published to support them in discovering and connecting to FHIR endpoints.
                    </P>
                    <HD SOURCE="HD3">16. New Certification Criteria for Modular API Capabilities</HD>
                    <HD SOURCE="HD3">a. Proposal Background</HD>
                    <P>We propose to add a new paragraph (j) to § 170.315 titled “modular API capabilities.” This new certification criteria category would promote the Program's modular certification approach and, importantly, would enable different combinations of capabilities across Health IT Modules depending on future use case needs. In general, we expect the capabilities in § 170.315(j) would be standards-based and include a combination of new and existing standards, many of which are currently referenced in § 170.315(g)(10). Additionally, we anticipate that the proposed capabilities in § 170.315(j) would enable the Program to better support a growing number of clinical, public health, and administrative use cases over the long-term, as well as foster innovation and competition in these spaces by providing flexibility for modular development approaches among developers of certified health IT.</P>
                    <P>
                        Section 4002 of the Cures Act requires health IT developers, as a condition of certification, to publish APIs that allow “health information from such technology to be accessed, exchanged, and used 
                        <E T="03">without special effort</E>
                         through the use of APIs or successor technology or standards, as provided for under applicable law.” (emphasis added). 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.” In the ONC Cures Act Final Rule (85 FR 25740), we described our approach to adopting a standardized API for patient and population services certification criterion in § 170.315(g)(10). The Standardized API for Patient and Population Services in § 170.315(g)(10) certification criterion includes conformance requirements for a combination of standards—including data content standards (such as the USCDI standard) and technical standards (such as the SMART App Launch implementation specification for authentication and authorization)—and functional criteria for other technical capabilities (such as application registration and token introspection). Since 2020, the standards development community has undertaken work to: (1) update existing standards and implementation specifications (
                        <E T="03">e.g.,</E>
                         US Core IG from version 3.1.1 to 7.0.0) 
                        <SU>166</SU>
                        <FTREF/>
                        ; (2) formalize previously functional capabilities as part of implementation specifications (
                        <E T="03">e.g.,</E>
                         token introspection is now part of SMART App Launch 2.0) 
                        <SU>167</SU>
                        <FTREF/>
                        ; and (3) support new and revised capabilities that are modular and use case agnostic (
                        <E T="03">e.g.,</E>
                         HL7 CDS Hooks,
                        <SU>168</SU>
                        <FTREF/>
                         FHIR Subscriptions,
                        <SU>169</SU>
                        <FTREF/>
                         and UDAP Security FHIR IG).
                        <SU>170</SU>
                        <FTREF/>
                         These developments have changed the heath IT landscape and helped support a wider range of potential technical solutions for healthcare use cases that previously may not have been supported, or were ineffectively supported, by health IT.
                    </P>
                    <FTNT>
                        <P>
                            <SU>166</SU>
                             
                            <E T="03">https://hl7.org/fhir/us/core/history.html.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>167</SU>
                             
                            <E T="03">https://hl7.org/fhir/smart-app-launch/STU2/token-introspection.html.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>168</SU>
                             
                            <E T="03">https://cds-hooks.hl7.org/.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>169</SU>
                             
                            <E T="03">https://hl7.org/fhir/uv/subscriptions-backport/STU1.1/.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>170</SU>
                             
                            <E T="03">https://build.fhir.org/ig/HL7/fhir-udap-security-ig/branches/main/index.html.</E>
                        </P>
                    </FTNT>
                    <P>
                        Over time, we have made updates to previously adopted certification criteria based on the evolution of available standards to support more advanced use cases leveraging similar functionality and increasingly interconnected health IT systems. In addition, we have sought to continuously improve the extensibility of specific conformance requirements so that those conformance requirements can support functionality in different types of health IT, and so that complex systems can be certified in a modular fashion. By using the term “modular” we mean certification criteria in the Program that are scoped to limited capabilities to enable health IT developers to certify to the specific certification criteria that apply to Health IT Modules they wish to certify, rather than large, multi-functionality, and all-encompassing certification criteria that would give developers less flexibility for certifying in the Program. The work to support extensibility and modularity of certification criteria within the Program has included cross-referencing aligned standards or capabilities across other certification criteria, which support consistent standards and functionality for related actions both across and within certified capabilities. For example, the certification criterion in § 170.315(b)(2) clinical information reconciliation and incorporation references the same standards referenced throughout the transitions of care certification criterion in § 170.315(b)(1), including § 170.205(a)(3) through (5), and the privacy and security certification criteria in § 170.315(d) are conditionally required for certification according to Health IT Module certification requirements for ONC-ACBs described in the privacy and security certification framework in § 170.550(h). Establishing the privacy and security certification framework in § 170.550(h) for ONC-ACBs ensures that Health IT Modules are subject to more specific privacy safeguards and provides more flexibility for certified health IT developers than would be the case if we had a single, 
                        <PRTPAGE P="63568"/>
                        multi-functionality privacy and security criterion.
                    </P>
                    <P>
                        Throughout the Program's history, we have also adopted both certification criteria that include the full scope of a complex transaction (
                        <E T="03">e.g.,</E>
                         § 170.315(b)(3) electronic prescribing) and certification criteria that include a discrete portion of a transaction (
                        <E T="03">e.g.,</E>
                         § 170.315(c)(1)-(4) clinical quality measures). These different approaches are intended to align our Program requirements to real world implementation scenarios which necessitate both contained execution of complex transactions and the ability to implement related processes across a range of systems in a modular fashion. Our adoption of these varying types of certification criteria allows ONC to administer a more effective and efficient Program, gives developers of certified health IT more nuanced certification options to meet their customers' needs, and promotes a more dynamic marketplace of certified Health IT Modules than would be the case if we bundled different functionalities and standards under fewer certification criteria.
                    </P>
                    <P>
                        Based on our analysis of the continued evolution of standards and the real-world implementation scenarios for certified health IT to enable FHIR-based APIs, we are proposing to adopt new certification criteria supporting API capabilities for public health data exchange and patient, provider, and payer data exchange (see sections III.B.13 and III.B.20 respectively). As described in this section, we are proposing to revise § 170.315(g)(10) through references to modular API capabilities proposed as certification criteria in § 170.315(j). These certification criteria include standards, functionalities, and certification conformance requirements that align with or are the exact same as the standards, functionalities, and certification conformance requirements currently referenced in § 170.315(g)(10). In addition, we are proposing to update the § 170.315(g)(10) certification criterion to cross-reference newly proposed requirements. Specifically, we propose to adopt a suite of modular API capabilities as certification criteria in § 170.315(j) where each criterion focuses on one specific certification conformance requirement, and we propose to reference these certification criteria as applicable in the proposed revisions to the § 170.315(g)(10) certification criterion (see section III.B.19). For example, we propose to include in § 170.315((j)(1) functional registration, (j)(6) SMART App Launch user authorization, (j)(7) SMART Backend Services system authentication and authorization, (j)(9) SMART Patient Access for Standalone Apps, (j)(10) SMART Clinician Access for EHR Launch. However, we also propose to include in these proposed certification criteria in § 170.315(j) new certification conformance requirements that reflect more recent API standards advancements (
                        <E T="03">e.g.,</E>
                         workflow triggers, verifiable health records, and subscriptions) further described below.
                    </P>
                    <HD SOURCE="HD3">b. Modular API Capabilities Certification Criteria</HD>
                    <P>We propose to adopt fourteen new modular API technology certification criteria in § 170.315(j) at (j)(1)-(2), (5)-(11), and (20)-(24). We propose to reserve (j)(3)-(4) and (12)-(19). These new certification criteria would be available for certification based on certain contexts or other programs requiring the use of the specified certified capabilities. Many of these certification criteria are substantially similar to capabilities currently referenced in § 170.315(g)(10)(iii) through (vii). We invite readers to review 85 FR 25739 through 25748 for discussion relevant to capabilities currently referenced in § 170.315(g)(10).</P>
                    <P>
                        In § 170.315(j)(1), we propose the “Functional registration” certification criterion which would require that a Health IT Module demonstrate the ability for applications to register with its authorization server. The process of registration is necessary in many health IT workflows and enables an authorization server to establish a scope of information access for applications and share authentication credentials if applicable. This requirement would be similar to what currently exists in § 170.315(g)(10)(iii) “Application registration,” which has a functional requirement to “enable an application to register with the Health IT Module's `authorization server.' ” We clarify that for the proposed requirement in § 170.315(j)(1) Health IT Modules presented for testing and certification must support application registration regardless of the scope of patient search utilized by the application (
                        <E T="03">e.g.,</E>
                         single or multiple). Additionally, this proposed certification criterion would require a health IT developer to demonstrate its registration process without requiring the use of an identified standard.
                    </P>
                    <P>In § 170.315(j)(2), we propose the “Dynamic registration” certification criterion where a Health IT Module demonstrates the ability to dynamically register confidential apps according to the implementation specifications adopted in § 170.215(o), including mandatory support for sections “Home,” “Discovery,” and “Registration” as well as the “community” query parameter as defined in the “Multiple Trust Communities” section of the implementation specifications adopted in § 170.215(o). As described in more detail at section III.B.15 of this proposed rule, the UDAP Security IG v1 would provide a more uniform, standardized, and automated registration pathway for applications.</P>
                    <P>We propose to reserve § 170.315(j)(3) and (j)(4) for future potential registration capabilities.</P>
                    <P>In § 170.315(j)(5), we propose to adopt the “Asymmetric certificate-based authentication for patient access” certification criterion where a Health IT Module's authorization server must support authentication during the process of granting access to patient data to patients according to the implementation specifications adopted in § 170.215(o), including support for asymmetric certificate-based authentication as detailed in section “Consumer-Facing” of the implementation specifications adopted in § 170.215(o). Asymmetric certificate-based authentication is a process by which the client and server use public and private keys along with digital certificates for authentication. It is a similar process to asymmetric authentication with the modification that both the client and server verify each other's participation in a trust community. The client and server represent their participation in a trust community through a digital certificate issued by the trust community's certificate authorities. We note that asymmetric certificate-based authentication supports the dynamic client registration proposals included in this rule for adoption in § 170.215(o)(1) (see the section titled New Requirements to Support Dynamic Client Registration Protocol in the Program).</P>
                    <P>
                        In § 170.315(j)(6) we propose to adopt the “SMART App Launch user authorization” certification criterion where a Health IT Module's authorization server must support user authorization during the process of granting access to patient data according to at least one implementation specification adopted in § 170.215(c). We note for this proposal that “user” refers to the end-user of an application, and may refer to either a patient, or a healthcare professional or his or her office staff. We clarify for the purposes of certification to this criterion that support for one type of user is sufficient (
                        <E T="03">e.g.,</E>
                         support for a patient user, or 
                        <PRTPAGE P="63569"/>
                        support for a healthcare professional or his or her office staff user). The specific requirements include requiring support for Health IT Modules to issue a refresh token valid for a period of no less than three months to confidential apps and native apps capable of securing a refresh token in § 170.315(j)(6)(i), receive and validate tokens issued by the Health IT Module in accordance with at least one implementation specification adopted in § 170.215(c) in § 170.315(j)(6)(ii), and enable for confidential apps persistent access to patient information without requiring user re-authentication or re-authorization until authorization revocation at the user's direction in § 170.315(j)(6)(iii). We further propose in § 170.315(j)(6)(iv) that a Health IT Module's authorization server must be able to revoke and must revoke an authorized application's access at a user's direction within 1 hour of the request. This proposed certification criterion includes the same functions for refresh tokens from § 170.315(g)(10)(v)(A) “Authentication and authorization for patient and user scopes” as well as authorization revocation and token introspection functions from § 170.315(g)(10)(vi) and (vii), respectively. Regarding support for the issuance of refresh tokens for native apps for this certification criterion, we mirror the conformance expectations established in the Information Blocking and the ONC Health IT Certification Program: Extension of Compliance Dates and Timeframes in Response to the COVID-19 Public Health Emergency Interim Final Rule (85 FR 70076), namely that health IT developers can determine the method(s) they use to support interactions with native apps and that health IT developers are not required to support all methods that third-party application developers seek to use.
                    </P>
                    <P>In § 170.315(j)(7), we propose to adopt the “SMART Backend Services system authentication and authorization” certification criterion where a Health IT Module would support system authentication and authorization during the process of granting a system access to patient data in accordance with the backend services profile of at least one implementation specification adopted in § 170.215(c). This certification criterion's conformance requirements are derived from what currently exists in § 170.315(g)(10)(v)(B) “Authentication and authorization for system scopes,” proposed in § 170.315(j)(7), as well as the token introspection requirements from § 170.315(g)(10)(vii), proposed in § 170.315(j)(7)(i). The proposed token introspection requirements in § 170.315(j)(7)(i) include requiring that a Health IT Module's authorization server must be able to receive and validate tokens it has issued in accordance with at least one implementation specification adopted in § 170.215(c). The HL7 standards community re-organized their standards and moved the “SMART Backend Services: Authorization Guide” from the Bulk v1 IG (adopted in § 170.215(d)(1)) into the “Backend Services” section of the SMART Application Launch Implementation Guide Release 2.0.0 (adopted in § 170.215(c)(2)).</P>
                    <P>In § 170.315(j)(8), we propose to adopt the “Asymmetric certificate-based system authentication and authorization” certification criterion where a Health IT Module would support system authentication and authorization for the “client_credentials” grant type during the process of granting access to patient data according to the implementation specifications adopted in § 170.215(o), including support for the “Business-to-Business” section of the implementation specifications adopted in § 170.215(o). This certification criterion would support system authentication and authorization for business-to-business access use cases within supported trust communities. This certification criterion would be similar in function to the certification criterion proposed in § 170.315(j)(7) in that it would require system authentication and authorization capabilities but would additionally require support for contextual information and certificates as detailed in the UDAP Security IG v1 to enable authentication and authorization within a trust community. Additionally, we propose to include a section for “Token introspection” in § 170.315(j)(8)(i), where a Health IT Module's authorization server must be able to receive and validate tokens it has issued in accordance with at least one implementation specification adopted in § 170.215(c). This requirement would be similar to what currently exists in § 170.315(g)(10)(vii) “Token introspection” and is aligned with similar token introspection requirements in § 170.315(j)(6)(ii) and (7)(i).</P>
                    <P>In § 170.315(j)(9), we propose to adopt the “SMART Patient Access for Standalone Apps” certification criterion where the Health IT Module would support patient authorization and authorization revocation at a patient's direction according to the requirements in § 170.315(j)(6). The capabilities described in the SMART Application Launch Framework Implementation Guide have matured and changed over time, and to support a health IT developer's ability to certify using any of the available implementation specifications in § 170.215(c) we propose allowing health IT developers to support one of the following sets of SMART capabilities listed in paragraph (j)(9)(i), (ii), and (iii). We also note that versions of the SMART Application Launch Framework Implementation Guide adopted in § 170.215(c) will expire on January 1, 2026 for § 170.215(c)(1), and January 1, 2028 for § 170.215(c)(2), and this proposed structure in § 170.315(j)(9) will support the transition to newer versions of the implementation specification. The first set of SMART capabilities requires up to and including December 31, 2025, support for the “Patient Access for Standalone Apps” Capability Set, as well as the capabilities of “launch-standalone” and “context-standalone-patient,” and the capabilities in subsections “Client Types,” “Single Sign-on,” and “Permissions” except the “permission-user” from § 170.215(c)(1). The second set of SMART capabilities requires up to and including December 31, 2027, support for “Patient Access for Standalone Apps” Capability Set as well as the capabilities of “launch-standalone” and “context-standalone-patient,” and the capabilities in subsections “Authorization Methods,” “Client Types,” “Single Sign-on,” and “Permissions” except the “permission-online” and “permission-user” capabilities from § 170.215(c)(2). The third set of SMART capabilities requires on and after January 1, 2028, support the “Patient Access for Standalone Apps” Capability Set as well as the capabilities of “launch-standalone” and “context-standalone-patient,” and the capabilities in subsections “Authorization Methods,” “Client Types,” “Single Sign-on,” and “Permissions” except the “permission-online” and “permission-user” capabilities from § 170.215(c)(3). In addition to requiring the foundational SMART App Launch capabilities for user authorization from proposed § 170.315(j)(6), this certification criterion adds requirements to support SMART App Launch capabilities to enable patients to authorize apps to access information using the SMART standalone launch process.</P>
                    <P>
                        In § 170.315(j)(10), we propose the “SMART Clinician Access for EHR Launch” certification criterion where the Health IT Module would support user authorization and authorization revocation at a user's direction according to the requirements in 
                        <PRTPAGE P="63570"/>
                        § 170.315(j)(6)(i)-(iii), including mandatory support for one of three sets of SMART capabilities to facilitate user access using EHR launch, proposed in § 170.315(j)(10)(i)(A), (B), and (C). The proposal describes that for the time period up to and including December 31, 2025, a Health IT Module must meet either the requirements specified in paragraph § 170.315(j)(10)(i)(A), (B), or (C); for the time period up to and including December 31, 2027, a Health IT Module must meet either the requirements specified in paragraph § 170.315(j)(10)(i)(B) or (C); and finally on and after January 1, 2028, a Health IT Module must meet the requirements specified in paragraph § 170.315(j)(10)(i)(C).
                    </P>
                    <P>The first set of SMART capabilities proposed in § 170.315(j)(10)(A) requires support for the “Clinician Access for EHR Launch” Capability Set as well as the capabilities of “launch-ehr,” “context-banner,” “context-style,” and “context-ehr-patient” as well as the capabilities in subsections “Client Types,” “Single Sign-on,” and “Permissions” according to the implementation specification adopted in § 170.215(c)(1). The second set of SMART capabilities proposed in § 170.315(j)(10)(B) requires support for the “Clinician Access for EHR Launch” Capability Set as well as the capabilities of “launch-ehr,” “context-banner,” “context-style,” “context-ehr-patient,” and “context-ehr-encounter,” and the capabilities in subsections “Authorization Methods,” “Client Types,” “Single Sign-on,” and “Permissions” except the “permission-online” capability according to the implementation specification adopted in § 170.215(c)(2). The third set of SMART capabilities proposed in § 170.315(j)(10)(A) requires support for the “Clinician Access for EHR Launch” Capability Set as well as the capabilities of “launch-ehr,” “context-banner,” “context-style,” “context-ehr-patient,” and “context-ehr-encounter,” and the capabilities in subsections “Authorization Methods,” “Client Types,” “Single Sign-on,” and “Permissions” except the “permission-online” capability according to the implementation specification adopted in § 170.215(c)(3). In addition to requiring the foundational SMART App Launch capabilities for user authorization from proposed § 170.315(j)(6)(iv), this certification criterion adds requirements to support SMART App Launch capabilities to enable users to authorize apps to access information using the SMART EHR launch process.</P>
                    <P>As discussed in section “SMART App Launch 2.2” of this rule, we propose to no longer reference specific capabilities and sections of the SMART App Launch implementation guide under § 170.215(c). Instead, Program criteria would specify required capabilities of the SMART App Launch implementation guide. In alignment with that proposal, we propose the SMART capabilities as adopted in HTI-1 in § 170.215(c)(1) for SMART App Launch 1.0.0 and § 170.215(c)(2) for SMART App Launch 2.0.0 be moved to the proposed § 170.315(j)(6)-(10) certification criteria. We propose the SMART App Launch 1.0.0 capabilities relevant to patient access for standalone apps be specified at proposed § 170.315(j)(9)(i) and the capabilities relevant to clinician access for EHR launch be specified at proposed § 170.315(j)(10)(i)(A). Similarly, we propose the SMART App Launch 2.0.0 capabilities relevant to patient access for standalone apps be specified at proposed § 170.315(j)(9)(ii) and the capabilities relevant to clinician access for EHR launch be specified at proposed § 170.315(j)(10)(i)(B). Finally, we propose to include the SMART App Launch 2.2.0 capabilities in § 170.315(j)(9)(iii) for patient access and § 170.315(j)(10)(i)(C) for clinician access. We propose moving token introspection according to SMART App Launch 2.0.0 as adopted in § 170.215(c)(2) in HTI-1 Final Rule to requirements in the proposed certification criteria in § 170.315(j)(6)-(8), which includes (j)(6)(ii), (7)(i), and (8)(i). The proposed certification criteria in § 170.315(j)(9) and (10) would also include conformance dates for each set of required SMART App Launch capabilities that would enable developers as they present their products for certification to move to the newer requirements when they are ready and prior to when a particular conformance requirement may expire, and the other(s) become the new baseline.</P>
                    <P>In § 170.315(j)(11), we propose the “Asymmetric certificate-based authentication for B2B user access” certification criterion where the Health IT Module would support asymmetric certificate-based authentication for the “authorization_code” grant type during the process of granting access to patient data to users according to the implementation specifications adopted in § 170.215(o), including support for asymmetric certificate-based authentication as detailed in the “Business-to-Business” section of the implementation specifications adopted in § 170.215(o). This certification criterion would be similar to the certification criterion proposed in § 170.315(j)(5) in that it would require support for certificate-based authentication according to the UDAP Security IG v1. However, this certification criterion would be focused on business-to-business authentication requirements to enable users, not patients, access to information in a within a trust community.</P>
                    <P>We intend to reserve § 170.315(j)(12) through (j)(19) in anticipation of future standards-based capabilities that would be complementary to the certification criteria proposed for adoption in § 170.315(j)(1) through (j)(11).</P>
                    <P>
                        Beginning in § 170.315(j)(20), we propose a set of new standards-based capabilities. These capabilities are 
                        <E T="03">not</E>
                         derived from the existing conformance requirements specified in § 170.315(g)(10). Rather, they reflect more advanced capabilities enabled by the HL7 FHIR standard and related implementation guides. We propose to adopt “workflow triggers for decision support interventions—clients” in § 170.315(j)(20) and Workflow triggers for decision support interventions—services at (j)(21); “Verifiable health records” in § 170.315(j)(22); and “Subscriptions—server” in § 170.315(j)(23) and “Subscriptions—client” at (j)(24). We propose these modular certification criteria to be broadly applicable to various clinical, public health, and administrative use cases. Below, we describe and provide our rationale for each of these advanced capabilities proposed for inclusion in § 170.315(j)(20) through (24).
                    </P>
                    <HD SOURCE="HD3">i. § 170.315(j)(20) and (21) Workflow Triggers for Decision Support Interventions</HD>
                    <P>
                        We propose to adopt the CDS Hooks Release 2.0 implementation specification in § 170.215(f)(1) to support Program requirements for API-based workflow triggers for decision support interventions (as described in more detail in the next paragraph) in the proposed certification criteria in § 170.315(j)(20) and (j)(21). These certification criteria are proposed separately but are both related to the underlying specification in § 170.215(f)(1). The certification criterion proposed in § 170.315(j)(20) includes requirements for “clients” participating in API-based workflow triggers for decision support, and the certification criterion proposed in § 170.315(j)(21) includes requirements for “services” providing decision support services to clients.
                        <PRTPAGE P="63571"/>
                    </P>
                    <P>CDS Hooks is a specification that describes a “hook”-based pattern for invoking or triggering decision support from within a clinician's workflow (typically the “client” side of this pattern). This pattern facilitates a clinician's ability to either pull in results from decision support directly into a clinician's workflow or can be used to launch an interactive application.</P>
                    <P>
                        We propose that a Health IT Module presented for certification to § 170.315(j)(20) support the requirements of the implementation specification in § 170.215(f)(1) as a “CDS Client” including support for the registration of “CDS Services” according to the implementation specification in § 170.215(f)(1) in § 170.315(j)(20)(i) and support for authentication and authorization 
                        <SU>171</SU>
                        <FTREF/>
                         according to the implementation specification in § 170.215(f)(1) in § 170.315(j)(20)(ii). We also propose in § 170.315(j)(20)(iii) that Health IT Modules certified to § 170.315(j)(20) support the execution of decision support workflow triggers in accordance with the implementation specification in § 170.215(f)(1), as well as demonstrate the ability to send a decision support request to a CDS Service according to the implementation specification in § 170.215(f)(1), in § 170.315(j)(20)(iv). As part of the capability to send a decision support request to a CDS Service, we propose in § 170.315(j)(20)(iv)(A) that a Health IT Module support the ability to deliver a CDS Hook request with prefetched information according to the “Prefetch Template” section of the implementation specification in § 170.215(f)(1); support access to HL7 FHIR Resources via a RESTful API to support decision support intervention workflows according to the “FHIR Resource Access” section of the implementation specification in § 170.215(f)(1) in § 170.315(j)(20)(iv)(B); and support the receipt of a decision support response according to the implementation specification in § 170.215(f)(1) in § 170.315(j)(20)(iv)(C), including support the display of the contents of a decision support response to an end-user and support the ability to launch internal apps and SMART apps from decision support responses according to the implementation specification in § 170.215(f), including support for the “Link” field “appContext,” in § 170.315(j)(20)(iv)(C)(
                        <E T="03">1</E>
                        ) and § 170.315(j)(20)(iv)(C)(
                        <E T="03">2</E>
                        ), respectively.
                    </P>
                    <FTNT>
                        <P>
                            <SU>171</SU>
                             CDS Hooks Release 2.0 includes authentication and authorization of endpoints and identity of the CDS Client. We direct readers to the implementation specification for more detail.
                        </P>
                    </FTNT>
                    <P>
                        We propose that a Health IT Module presented for certification to § 170.315(j)(21) support the complementary aspects of the workflow trigger implementation specification in § 170.215(f)(1). Specifically, we propose these Health IT Modules support the requirements of the implementation specification in § 170.215(f)(1) as a “CDS Service” including support for registration of CDS Clients in § 170.315(j)(21)(i) and authentication and authorization according to the implementation specification in § 170.215(f)(1) in § 170.315(j)(21)(ii). In § 170.315(j)(21)(iii), we propose a Health IT Module respond to requests for recommendations and guidance via a RESTful API according to the implementation specification in § 170.215(f)(1), including capabilities to receive and process decision support requests in § 170.315(j)(21)(iii)(A); the ability to receive pre-fetched information according to the “Prefetch Template” section of the implementation specification § 170.215(f)(1) in § 170.315(j)(21)(iii)(A)(
                        <E T="03">1</E>
                        ); and the ability to fetch HL7 FHIR Resources via an API according to the “FHIR Resource Access” section of the implementation specification § 170.215(f)(1) in § 170.315(j)(21)(iii)(A)(
                        <E T="03">2</E>
                        ). Finally, we propose in § 170.315(j)(21)(iii)(B) that Health IT Modules support returning a decision support response according to the implementation specification in § 170.215(f)(1), including support for the “Link” field “appContext.”
                    </P>
                    <P>
                        We note that the proposed workflow triggers criteria in § 170.315(j)(20) and (j)(21) do not define or propose specific workflows associated with decision support, including how and when clinicians use decision support capabilities. Rather, we propose to include standards-based interfaces in § 170.315(j)(20) and (j)(21) to enable clinical systems to call other systems offering decision support services in a standardized manner to support the exchange and use of these services.
                        <E T="51">172 173 174</E>
                        <FTREF/>
                         We request comment on these proposals.
                    </P>
                    <FTNT>
                        <P>
                            <SU>172</SU>
                             Bradshaw, R.L., Kawamoto, K., Kaphingst, K.A., Kohlmann, W.K., Hess, R., Flynn, M. C., . . . Del Fiol, G. (2022). GARDE: a standards-based clinical decision support platform for identifying population health management cohorts. 
                            <E T="03">Journal of the American Medical Informatics Association: JAMIA, 29</E>
                            (5), 928-936. doi:10.1093/jamia/ocac028.
                        </P>
                        <P>
                            <SU>173</SU>
                             Morgan, K.L., Kukhareva, P., Warner, P.B., Wilkof, J., Snyder, M., Horton, D., . . . Kawamoto, K. (2022). Using CDS Hooks to increase SMART on FHIR app utilization: a cluster-randomized trial. 
                            <E T="03">Journal of the American Medical Informatics Association: JAMIA, 29</E>
                            (9), 1461-1470. doi:10.1093/jamia/ocac085.
                        </P>
                        <P>
                            <SU>174</SU>
                             Watkins, M., &amp; Eilbeck, K. (2020). FHIR Lab Reports: using SMART on FHIR and CDS Hooks to increase the clinical utility of pharmacogenomic laboratory test results. 
                            <E T="03">AMIA Summits on Translational Science proceedings, 2020,</E>
                             683-692.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">ii. § 170.315(j)(22) Verifiable Health Records</HD>
                    <P>
                        We propose that a Health IT Module presented for certification to § 170.315(j)(22) support the issuance of verifiable health records according to the SMART Health Cards Framework version 1.4.0 standard (SMART Health Cards), which we propose to adopt in § 170.215(g)(1)(i). SMART Health Cards specifies a framework for issuing records represented using HL7 FHIR structured information to users that can be verified by another party.
                        <SU>175</SU>
                        <FTREF/>
                         SMART Health Cards is based on international open standards. In addition to HL7 FHIR, SMART Health Cards incorporate DEFLATE Compression, JSON Web Token (JWT), JSON Web Key (JWK), JSON Web Key (JWK) Thumbprint, and HMAC-SHA-256.
                        <SU>176</SU>
                        <FTREF/>
                         SMART Health Cards support a decentralized infrastructure and addresses common concerns around verifying portable data. Once a SMART Health Card is generated, the data becomes verifiable to a point in time, which can then be shared at the patient's discretion via Quick-Response Code (QR code). QR Codes are two dimensional barcodes that can encode up to about 3Kb of data.
                        <SU>177</SU>
                        <FTREF/>
                         The QR Codes can be easily scanned via smartphones to access the SMART Health Card. We also propose to adopt the SMART Health Cards: Vaccination and Testing Implementation Guide version 1.0.0-rc—STU 1 Release Candidate,” in § 170.215(g)(2)(i), an HL7 FHIR implementation guide that leverages the SMART Health Cards Framework to describe standards-based methods for the issuance of verifiable health records for vaccination status and infectious disease-related laboratory testing.
                    </P>
                    <FTNT>
                        <P>
                            <SU>175</SU>
                             
                            <E T="03">https://smarthealth.cards/en/.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>176</SU>
                             
                            <E T="03">https://spec.smarthealth.cards/#what-software-libraries-are-available-to-work-with-smart-health-cards.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>177</SU>
                             
                            <E T="03">https://www.qrcode.com/en/about/.</E>
                        </P>
                    </FTNT>
                    <P>
                        The SMART Health Cards standard has seen rapid adoption in the past few years as a reliable and easy way for consumers to receive and share verifiable clinical information. Some notable use cases for verifiable records that have been implemented in clinical settings using the SMART Health Cards standard occurred during the COVID-19 public health emergency to support verifiable COVID-19 test results and 
                        <PRTPAGE P="63572"/>
                        COVID-19 vaccination records.
                        <E T="51">178 179</E>
                        <FTREF/>
                         In support of these and related use cases, we propose in § 170.315(j)(22)(i) that Health IT Modules support the “data minimization” and “allowable data” profiles of the following according to the implementation specification adopted in § 170.215(g)(2)(i): “Immunization Bundle,” “COVID-19 Labs Bundle,” and “Generic Labs Bundle,” “Patient—United States,” “Vaccination,” “Lab results COVID-19,” and “Lab results—Generic.” We propose in § 170.315(j)(22)(ii) that Health IT Modules support the “$health-cards-issue” operation via a standardized API according to the implementation specification adopted in § 170.215(g)(1)(i). We are also aware that the SMART Health Cards standard is going through the ballot and publication process at HL7 over the next several months. ONC encourages the community to follow along and can access the current CI Build at 
                        <E T="03">https://build.fhir.org/ig/HL7/smart-health-cards-and-links/cards-specification.html.</E>
                         If there is a published version of the SMART Health Cards standard prior to the publication of the final rule, we will consider adopting that version. We welcome comment on our proposals.
                    </P>
                    <FTNT>
                        <P>
                            <SU>178</SU>
                             Braunstein, M.L. (2022). SMART on FHIR. In: Health Informatics on FHIR: How HL7's API is Transforming Healthcare. Health Informatics. Springer, Cham. 
                            <E T="03">https://doi-org.hhsnih.idm.oclc.org/10.1007/978-3-030-91563-6_10.</E>
                        </P>
                        <P>
                            <SU>179</SU>
                             
                            <E T="03">https://www.thecommonsproject.org/shc.</E>
                        </P>
                    </FTNT>
                    <P>We also note that while we have not proposed nor are we seeking comment on the SMART Health Links technical specification that we are closely following its advances as well as industry uses for future rulemakings.</P>
                    <HD SOURCE="HD3">iii. § 170.315(j)(23) and (24) Subscriptions</HD>
                    <P>The HL7 FHIR Subscriptions Framework describes a standardized method for clients to subscribe to notifications from servers based on pre-negotiated criteria. Once the subscription is established, servers can proactively notify a client when new information has been added or existing information has been updated in its system. Once a notification has been received by a client, the client can take appropriate action, including querying the server for the desired information. The HL7 FHIR Subscriptions Framework also describes methods to transmit payloads with notifications, which may help simplify some interorganizational transactions by enabling real-time updates, selective data transmission, and interoperability, making data exchange between organizations more efficient and effective.</P>
                    <P>We anticipate that API-based subscriptions will support several use cases across clinical, public health, administrative and research domains. Specific to public health use cases, we envision that future implementation guides could leverage the HL7 FHIR Subscriptions Framework for case reporting processes, immunization reporting processes, syndromic surveillance, reportable laboratory tests and values, and transmitting cancer case information to state cancer registries, among others. We welcome comments on this approach, particularly with respect to the readiness of this standard to support public health reporting and any potential benefits or limitations to this approach that we should consider.</P>
                    <P>The HL7 FHIR Subscriptions Framework has undergone a significant redesign during the development of the HL7® FHIR® Release 5 (R5) standard, including the use of “SubscriptionTopic” HL7 FHIR Resources that define the criteria for standardized subscription notifications. We have structured our proposals in § 170.315(j)(23) and (24) to best accommodate health IT developers and the industry's maturity so that API-based subscriptions can be more easily implemented in the current health IT landscape. While the HL7 FHIR Subscriptions Framework in HL7® FHIR® R5 is well developed, the health IT industry is largely using HL7® FHIR® Release 4, Version 4.0.1 (HL7® FHIR® R4), for HL7 FHIR standards-based exchange. Updating all the criteria in the Program to HL7® FHIR® R5 to accommodate the updated HL7 FHIR Subscriptions Framework would not be practicable nor prudent given the full-scale industry redesign that would be necessary to do so and impacts on users. In order to enable health IT developers using HL7® FHIR® R4, to support the improvements made in the HL7 FHIR Subscriptions Framework in HL7® FHIR® R5, the HL7 standards community created the Subscriptions R5 Backport Implementation Guide version 1.1.0, which specifies some of the HL7® FHIR® R5 Subscriptions Framework enhancements in a way that is compatible with HL7® FHIR® R4.</P>
                    <P>We propose that a Health IT Module presented for certification to § 170.315(j)(23) or § 170.315(j)(24) support API-based subscriptions according to HL7 FHIR Subscriptions Framework included in the HL7 FHIR Subscriptions R5 Backport Implementation Guide version 1.1.0 (hereafter referred to as “Subscriptions IG”), which we propose to adopt in § 170.215(h)(1). The proposals in § 170.315(j)(23) and (24) specify constraints on the implementation specification proposed in § 170.215(h)(1), which intend to ensure that Health IT Modules certified to § 170.315(j)(23) or (24) can conform to separate but related aspects and functions of the implementation specification in § 170.215(h). Similar to the proposals in § 170.315(j)(20) and (21), we propose that Health IT Modules certified to § 170.315(j)(23) support subscriptions as a “server” and Health IT Modules certified to § 170.315(j)(24) support subscriptions as a “client” according to the implementation specification proposed in § 170.215(h)(1).</P>
                    <P>Recognizing the importance of reducing burden on health IT developers while also striving to improve nationwide interoperability, we propose to adopt the Subscriptions IG in § 170.215(h)(1) support certification criteria for API-based subscriptions in § 170.315(j)(23) subscriptions—server and § 170.315(j)(24) subscriptions—client requirements. The Subscriptions IG includes API-based subscription functionality that goes beyond the scope of FHIR R4, but for the purposes of the Program, we propose in § 170.315(j)(23)(i) and (24)(i), for servers and clients respectively, that Health IT Modules support the requirements specified in section “1.6 Topic-Based Subscriptions—FHIR R4” of the implementation specification in § 170.215(h)(1).</P>
                    <P>Additionally, we propose in § 170.315(j)(23)(ii) and (24)(ii), for servers and clients respectively, that Health IT Modules support the “R4/B Topic-Based Subscription” profile as specified in the Subscriptions IG. We note that while this profile is compatible with both HL7® FHIR® R4, and HL7® FHIR® R4B, we propose it for use with HL7® FHIR® R4, at this time.</P>
                    <P>
                        We also propose in § 170.315(j)(23)(iii) that Health IT Modules support the requirements described in the “R4 Topic-Based Subscription Server Capability Statement” of the implementation specification in § 170.215(h)(1), including support for “create,” “update,” and “delete” interactions for HL7 FHIR Subscription Resources according to the implementation specification in § 170.215(h)(1). We propose corresponding requirements for clients in § 170.315(j)(24)(iii), specifically that Health IT Modules support the accompanying client capabilities for the minimum requirements included in the “R4 
                        <PRTPAGE P="63573"/>
                        Topic-Based Subscription Server Capability Statement” of the implementation specification in § 170.215(h)(1), including support for “create,” “update,” and “delete” interactions for HL7 FHIR Subscription Resources according to the implementation specification in § 170.215(h)(1). We propose to require servers support the “create,” “update,” and “delete” interactions so that a client will be enabled to create, modify, and delete subscriptions on a server using a standardized API.
                    </P>
                    <P>Finally, we propose in § 170.315(j)(23)(iv) that Health IT Modules support the ability to send subscription notifications to subscribed clients, and in 170.315(j)(24)(iv) that Health IT Modules support the ability to receive subscription notifications, according to the “1.6 Topic-Based Subscriptions—FHIR R4” section of the implementation specification in § 170.215(h)(1). We propose to include in § 170.315(j)(23)(iv)(A) and (24)(iv)(A), for servers and clients respectively, that support for “id-only” Payload Types is required as specified in the “Payload Types” section of the implementation specifications in § 170.215(h)(1). There are three options available when specifying contents of a notification: empty, id-only, and full-resource. We believe that id-only provides a good balance between security and performance.</P>
                    <P>
                        Additionally, we propose in § 170.315(j)(23)(v) that Health IT Modules support the ability for a client to subscribe to a subscription topics and parameters defined in notifications by the subscription topics as defined in § 170.315(j)(23)(v)(A) and § 170.315(j)(23)(v)(B)(
                        <E T="03">1</E>
                        )-(
                        <E T="03">19</E>
                        ). We propose in § 170.315(j)(23)(A) to require Health IT Modules support USCDI change notifications which allows a client to subscribe to receive notifications filtered by a patient identifier and send notifications when any of the Resources specified in § 170.315(j)(23)(v)(B) are created or updated as applicable according to the standard in § 170.215(a) and implementation specification in § 170.215(h)(1). We further propose in § 170.315(j)(23)(v)(B) that Health IT Modules support resource notifications supporting the ability for a client to subscribe to notifications filtered according to the conditions below and send notifications for the following Resource interactions according to the standard in § 170.215(a) and implementation specification in § 170.215(h)(1):
                    </P>
                    <P>• “AllergyIntolerance” Resource is created or updated, including support for filtering subscription notifications using “category,” “code,” and “patient” data elements.</P>
                    <P>• “CarePlan” Resource is created or updated, including support for filtering subscription notifications using “category” and “subject” data elements.</P>
                    <P>• “CareTeam” Resource is created, or updated, including support for filtering subscription notifications using “category” and “subject” data elements.</P>
                    <P>• “Condition” Resource is created or updated, including support for filtering subscription notifications using “category,” “code,” and “subject” data elements.</P>
                    <P>• “Coverage” Resource is created or updated, including support for filtering subscription notifications using “beneficiary” and “type” data elements.</P>
                    <P>• “DiagnosticReport” Resource is created or updated, including support for filtering subscription notifications using “category,” “code,” and “subject” data elements.</P>
                    <P>• “DocumentReference” Resource is created or updated, including support for filtering subscription notifications using “subject” and “type” data elements.</P>
                    <P>• “Encounter” Resource is created or updated, including support for filtering subscription notifications using “reasonCode,” “subject,” and “type” data elements.</P>
                    <P>• “Goal” Resource is created or updated, including support for filtering subscription notifications using “category,” “description,” and “subject” data elements.</P>
                    <P>• “Immunization” Resource is created or updated, including support for filtering subscription notifications using “patient,” and “vaccineCode” data elements.</P>
                    <P>• “MedicationDispense” Resource is created or updated, including support for filtering subscription notifications using “category,” “medication[x],” and “subject” data elements.</P>
                    <P>• “MedicationRequest” Resource is created or updated, including support for filtering subscription notifications using “category,” “medication[x],” and “subject” data elements.</P>
                    <P>• “Observation” Resource is created or updated, including support for filtering subscription notifications using “category,” “code,” and “subject” data elements.</P>
                    <P>• “Patient” Resource is updated, including support for filtering subscription notifications using the “identifier” data element.</P>
                    <P>• “Procedure” Resource is created or updated, including support for filtering subscription notifications using “category,” “code,” and “subject” data elements.</P>
                    <P>• “QuestionnaireResponse” Resource is created or updated, including support for filtering subscription notifications using the “subject” data element.</P>
                    <P>• “RelatedPerson” Resource is created or updated, including support for filtering subscription notifications using the “patient” data element.</P>
                    <P>• “ServiceRequest” Resource is created or updated, including support for filtering subscription notifications using “category,” “code,” and “subject” data elements.</P>
                    <P>• “Specimen” Resource is created or updated, including support for filtering subscription notifications using “patient” and “type” data elements.</P>
                    <P>We believe our proposal in § 170.315(j)(23)(v) reflects the public feedback we received during the HTI-1 rulemaking process. Several commenters recommended that the subscription criterion focus on retrieving patient data associated with a specific patient ID as a starting point.</P>
                    <P>
                        Proposals in § 170.315(j)(23) and § 170.315(j)(24) included in this section reflect public feedback we received in the HTI-1 Proposed Rule. For § 170.315(j)(23), in the HTI-1 Proposed Rule, we received feedback supporting subscription notification for patient data associated with a specific patient ID that allows for notifications based on new or updated data associated with the patient's resources. The proposed resources specified in § 170.315(j)(23)(v)(B) are a subset of USCDI/US Core IG Resources filtered to include those that are part of the HL7 FHIR “Compartment Patient” 
                        <SU>180</SU>
                        <FTREF/>
                         and are widely supported across the healthcare industry. We believe that aligning subscription requirements with US Core resources that are required across several ONC certification Program criteria will contribute to better data exchange, improved patient care, and more effective health IT systems.
                    </P>
                    <FTNT>
                        <P>
                            <SU>180</SU>
                             
                            <E T="03">https://hl7.org/fhir/R4/compartmentdefinition-patient.html.</E>
                        </P>
                    </FTNT>
                    <P>We seek public comment on the listed US Core resources in § 170.315(j)(23)(v)(B), and we alternately propose to require client servers to support the ability for a client to subscribe to notifications filtered by all, meaning any, USCDI/US Core resources for “category,” “code,” and “subject” data elements where applicable.</P>
                    <P>
                        We additionally propose to include in § 170.315(j)(23)(iv)(B) that at a minimum, support for the “REST-Hook” channel is required for sending subscription notifications to clients as specified in the “Channels” section of the implementation specifications in § 170.215(h)(1). The REST-hook channel 
                        <PRTPAGE P="63574"/>
                        uses the RESTful model which is extensively used in FHIR standard and is considered to present the lowest bar for implementation. Finally, we propose to include in § 170.315(j)(24)(iv)(B) required support for consuming notifications via the “REST-Hook” channel as specified in the “Channels” section of the implementation specifications in § 170.215(h)(1).
                    </P>
                    <P>We note that we have included references to the proposed certification criterion in § 170.315(j)(23) in two proposed certification criteria in § 170.315(g)(20) and § 170.315(g)(35) and refer readers to those sections for more information on the proposals. Additionally, we have included a reference to the proposed certification criterion in § 170.315(j)(24) in the proposed certification criterion in § 170.315(g)(34) and refer to that section for more information on the proposals.</P>
                    <P>We believe our proposal and alternative proposals in § 170.315(j)(23) and § 170.315(j)(24) reflect the public feedback we received during the HTI-1 rulemaking process. We acknowledge that the standards may have matured beyond the prior recommended feedback from the HTI-1 Proposed Rule and request comment on these proposals and whether interested individuals and organizations would prefer to implement other standards listed in the Subscriptions IG, including API-based subscriptions based on HL7 FHIR R5.</P>
                    <HD SOURCE="HD3">17. Multi-Factor Authentication Criterion</HD>
                    <HD SOURCE="HD3">a. Background</HD>
                    <P>
                        In the ONC Cures Act Final Rule, we finalized a “multi-factor authentication” (MFA) certification criterion in § 170.315(d)(13) and applied it to all certification criteria across the privacy &amp; security (P&amp;S) certification framework (85 FR 25700). Through this certification criterion and the P&amp;S Certification Framework, we established an approach that required health IT developers to be transparent about whether their certified Health IT Module supports MFA. As part of the certification process, developers' “yes” or “no” attestations are made public on ONC's Certified Health IT Product List (CHPL) which is accessible here: 
                        <E T="03">https://chpl.healthit.gov/.</E>
                    </P>
                    <P>We established this approach in acknowledgement that “MFA may not be appropriate or applicable in all situations” and that “there is a wide variation in authentication needs and approaches throughout the industry” (85 FR 25701). We also acknowledged some of the challenges with adopting MFA in healthcare, noting comments expressing concern that it could increase provider burden (85 FR 25701). We therefore finalized our current approach to allow for developers to attest “no” as a certification option, and to promote increased transparency into these “no” attestations, we included a provision that permitted health IT developers attesting “no” to explain why their Health IT Module does not support MFA. Any optional explanations provided were also made available to the public on the CHPL as part of the certification process.</P>
                    <HD SOURCE="HD3">b. Proposal</HD>
                    <P>
                        We propose to update the requirements in the “Multi-factor authentication” certification criterion in § 170.315(d)(13) to increase support for MFA in certified health IT without imposing additional requirements on health care providers. We believe these updates match industry information security best practice for important authentication use cases in health IT and that it is necessary to help better protect electronic health information. We propose to expire our current “yes” or “no” attestation requirements by moving them to § 170.315(d)(13)(i) and including an applicability date for the time period up to and including December 31, 2027 in § 170.315(d)(13). We propose to replace the attestation requirements by revising § 170.315(d)(13) to include the new requirements in § 170.315(d)(13)(ii) that become required for continued conformance on and after January 1, 2028. We propose with these new requirements to require, in § 170.315(d)(13)(ii)(A), Health IT Module support for authentication, through multiple elements of the user's identity, according to industry recognized standards. Additionally, we propose, in § 170.315(d)(13)(ii)(B), to require that Health IT Modules certified to the criterion provide functionality that allows users (
                        <E T="03">e.g.,</E>
                         providers and patients) to configure, enable and disable these multi-factor authentication capabilities. Lastly, we propose that a health IT developer may meet the proposed revised certification criterion's requirements just by satisfying the new conformance requirements proposed in § 170.315(d)(13)(ii) in lieu of § 170.315(d)(13)(i) prior to paragraph (i)'s December 31, 2027, expiration.
                    </P>
                    <P>
                        We expect that Health IT Modules certifying to this MFA criterion must have the ability to authenticate users using multiple means to confirm that users are who they claim to be. Multiple means of authentication in this context includes using two or more of the following: (i) Something people know, such as a password or a personal identification number (PIN); (ii) something people have, such as a phone, badge, card, RSA token or access key; and (iii) something people are, such as fingerprints, retina scan, heartbeat, and other biometric information (85 FR 25701). Examples of industry recognized standards for MFA include NIST Special Publication 800-63B Digital Identity Guidelines, and ISO 27001.
                        <SU>181</SU>
                        <FTREF/>
                         As we stated in 2019, when we first proposed MFA requirements in the Program, a government led initiative and numerous organizations and groups recommend the use of MFA (84 FR 7451). More recently, the HHS Office for Civil Rights has identified weakened healthcare authentication measures as one of the biggest causes of data breaches in recent years.
                        <SU>182</SU>
                        <FTREF/>
                         We believe our proposal helps improve security by increasing access to MFA. This is because it is less likely that an unauthorized individual or entity will be able to succeed in proving one's identity when more than one authentication factor is used.
                    </P>
                    <FTNT>
                        <P>
                            <SU>181</SU>
                             NIST Special Publication 800-63B: 
                            <E T="03">https://pages.nist.gov/800-63-3/sp800-63b.html;</E>
                             ISO 27001: 
                            <E T="03">https://www.iso.org/standard/27001.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>182</SU>
                             
                            <E T="03">https://www.hhs.gov/hipaa/for-professionals/security/guidance/cybersecurity-newsletter-june-2023/index.html.</E>
                        </P>
                    </FTNT>
                    <P>
                        We also propose corresponding revisions in the principles of proper conduct for ONC-ACBs in § 170.523(m) and the privacy and security certification framework in § 170.550(h)(3). In § 170.523(m)(3) we propose to time-limit the applicability of § 170.315(d)(13) for the time period up to and including December 31, 2027. After this date, ONC-ACBs will no longer be required to obtain a record of updates from health IT developers to describe MFA use cases. Additionally, we propose to apply the updated MFA requirements to each of the certification criteria in § 170.315(b)(3), (e)(1), (g)(10), and (g)(30). Specifically, in §§ 170.315(b)(3)(ii)(G), 170.315(e)(1)(iii), 170.315(g)(10)(ii)(A)(
                        <E T="03">1</E>
                        )(
                        <E T="03">iii</E>
                        ), and 170.315(g)(30)(ii)(C) we propose to include a requirement that on and after January 1, 2028, Health IT Modules certified to any of these criteria are also certified to § 170.315(d)(13)(ii). Given our proposal to embed § 170.315(d)(13) references into the certification criteria we propose requiring MFA support in, § 170.315(d)(13) does not need to also be referenced in § 170.550(h)(3)(i) through (ix). Therefore, we propose to expire all the references to § 170.315(d)(13) in § 170.550(h)(3)(i) through (ix) by time-limiting the applicability of § 170.315(d)(13) in § 170.550(h)(3)(i) 
                        <PRTPAGE P="63575"/>
                        through (ix) for the time period up to and including December 31, 2027.
                    </P>
                    <P>
                        We clarify that Health IT Modules certified to § 170.315(g)(10) and § 170.315(g)(30), on and after January 1, 2028, would be required to support MFA for patient scopes or patient-facing authentication use cases, rather than non-patient (
                        <E T="03">i.e.,</E>
                         clinical user) and system-level use cases. We also clarify that Health IT Modules certified to § 170.315(b)(3) on and after January 1, 2028, would have the option of meeting the requirement to support MFA in this certification criterion by supporting user level MFA for electronic prescribing of a controlled substance.
                        <SU>183</SU>
                        <FTREF/>
                         With respect to Health IT Modules certified to § 170.315(b)(3) that do not support electronic prescribing of a controlled substance, we propose that they must still demonstrate support for MFA for some other user authentication use case. We welcome comment on these proposals. We also request comment on whether we should consider in the final rule exempting Health IT Modules from the MFA requirement when they are only designed to support non-controlled substance electronic prescribing. We would also appreciate any statistics, if available, on the market segment that would be affected by this specific policy.
                    </P>
                    <FTNT>
                        <P>
                            <SU>183</SU>
                             Multi-factor authentication for electronic prescribing of controlled substances is required to meet the Electronic Prescribing of Controlled Substances (EPCS) requirements set by Drug Enforcement Administration (DEA).
                        </P>
                    </FTNT>
                    <P>Finally, we propose to modify § 170.550(h)(3)(viii) to require that Health IT Modules certified to § 170.315(g)(20) and (g)(30) through (36), in addition to § 170.315(g)(7) through (g)(10) as is currently required, are also certified to the certification criteria specified in § 170.315(d)(1), (9), (12), and, for the time period up to and including December 31, 2027, § 170.315 (d)(13); and (d)(2)(i)(A) and (B), (d)(2)(ii) through (v), or (10). We similarly propose, in § 170.550(h)(3)(x), that Health IT Modules certified to any criterion proposed in § 170.315(j) are also certified to the certification criteria specified in § 170.315(d)(1), (d)(2)(i)(A) and (B), (d)(2)(ii) through (v), (d)(3), and (12). We welcome comment on this proposal including whether we should require testing for § 170.315(d)(13) in any of the certification criteria in § 170.315(j).</P>
                    <HD SOURCE="HD3">18. Revised Computerized Provider Order Entry—Laboratory Criterion</HD>
                    <P>The laboratory-based workflow is initiated when a clinician orders a test (such as part of a routine screening or a diagnostic work up). If the clinician does not provide all of the information requested in the test order, or if the test order does not request specific data, the laboratory or the public health authority receiving the laboratory results will not have complete information. Such missing information could include patient demographics, creating gaps in understanding and addressing issues related to health equity, in addition to direct issues with contact tracing and patient outreach that could slow down the spread of infectious disease.</P>
                    <P>Laboratory orders are often initiated in EHR systems when ordered by clinicians practicing in hospitals or large healthcare organizations. The laboratory provides the results from the test back to the ordering clinician by various means via their Laboratory Information Management Systems (LIMS) or Laboratory Information Systems (LIS). Ensuring that systems that create orders are also capable of transmitting orders and receiving associated results and values back electronically, according to national standards, will create more complete patient information available to clinicians throughout the laboratory workflow.</P>
                    <P>We propose to revise the “computerized provider order entry—laboratory” certification criterion in § 170.315(a)(2) by requiring Health IT Modules certified to this criterion to create and transmit laboratory orders electronically, to be performed according to the Lab Orders Interface (LOI) Implementation Guide proposed at 170.205(g)(2) and the Lab Results Interface (LRI) Implementation Guide proposed in § 170.2015(g)(3). Specifically, we propose to implement our proposed revisions by moving our existing § 170.315(a)(2) requirements into paragraphs § 170.315(a)(2)(i) that expire on January 1, 2026, and by including new standards-based requirements for lab orders in § 170.315(a)(2)(ii) that must be met on and after January 1, 2028.</P>
                    <P>We propose to revise § 170.315(a)(2) by establishing a new subparagraph in § 170.315(a)(2)(ii) to include requirements for Health IT Modules certified to § 170.315(a)(2) to enable a user to create and transmit laboratory orders electronically, to be performed according to the LOI Implementation Guide (§ 170.205(g)(2)) cross-referenced in § 170.315(a)(2)(ii)(B). We further propose to require Health IT Modules certified to § 170.315(a)(2) to enable a user to receive and validate laboratory results according to the LRI Implementation Guide (§ 170.205(g)(3)) cross-referenced in § 170.315(a)(2)(ii)(C).</P>
                    <P>As discussed in our proposals relevant to § 170.315(f)(3), in section III.B.13.d., the LRI and LOI IGs reduce some of the optionality that is present in currently implemented specifications, which may improve the completeness of information. For example, the LRI and LOI implementation guides require ordering provider, patient address, patient phone number, and patient race. Further, the LRI IG aligns with Clinical Laboratory Improvement Amendments of 1988 (CLIA) requirements in place for laboratories. The update to these specifications, and the inclusion of the receipt of orders in § 170.315(f)(3), as well as the receipt of results in § 170.315(a)(2), ensure that functions throughout the lifecycle of the laboratory order, from entry, to result, to reporting to public health authority, is covered by electronic requirements with the associated national standard.</P>
                    <P>We propose that for the time period up to and including December 31, 2027, a Health IT Module certified to § 170.315(a)(2) must meet either the requirements specified in paragraph (a)(2)(i), or the requirements specified in paragraph (a)(2)(ii). On and after January 1, 2028, for Health IT Modules certified to § 170.315(a)(2), we propose that such Health IT Modules must meet the requirements specified in paragraph (a)(2)(ii).</P>
                    <P>We welcome comment on these proposals.</P>
                    <HD SOURCE="HD3">19. Revised Standardized API for Patient and Population Services Criterion To Align With Modular API Capabilities</HD>
                    <P>
                        As part of our overall proposal, we propose to revise the structure of the regulation text in § 170.315(g)(10) for clarity as well as phrasing consistency with other proposed API certification criteria in this proposed rule (
                        <E T="03">e.g.,</E>
                         the proposed applicable § 170.315(j) criteria). These revisions to the regulation text's structure are intended to improve readability and how the certification criterion's requirements are organized. Generally, these specific reorganizing revisions are not intended to introduce substantive changes to current conformance requirements. A notable exception is the proposed reference to certification criterion requirements proposed in § 170.315(j)(10)(ii), which would be a new requirement for user authorization revocation. We also note that we have included proposals that introduce new, substantive requirements as well to § 170.315(g)(10) with applicable conformance timing. These details are discussed below and, as applicable, 
                        <PRTPAGE P="63576"/>
                        proposed § 170.315(j) certification criteria requirements will be discussed along with current and proposed § 170.315(g)(10) requirements to show a complete view of all proposed revisions to the § 170.315(g)(10) certification criterion's regulation text.
                    </P>
                    <P>We propose to revise the § 170.315(g)(10) certification criterion to reference applicable proposed § 170.315(j) certification criteria to make the regulation text of § 170.315(g)(10) more concise, clear, and consistent with the other proposed API certification criteria. In section III.B.16 of this proposed rule, we discuss our proposal to add a new category of certification criteria in § 170.315(j) titled “Modular API capabilities.” The § 170.315(j) certification criteria, if finalized, would allow for specific API certification requirements to be demonstrated independently or in different combinations through the Program in circumstances where meeting all of § 170.315(g)(10)'s requirements would not be applicable. These proposed changes, taken together, would help the Program support APIs across clinical, public health, administrative, and other use cases.</P>
                    <HD SOURCE="HD3">a. Proposed Revisions for Registration</HD>
                    <P>We propose to reorganize and rephrase the application registration requirements currently in § 170.315(g)(10)(iii). The current application registration requirements in § 170.315(g)(10)(iii) require support for an application to register with the Health IT Module's “authorization server” to support retrieval of data for a single patient's data and multiple patients' data. No standard is currently specified for registration. We propose to rename § 170.315(g)(10)(i) as “Registration,” and move the existing application registration requirements from § 170.315(g)(10)(iii) to § 170.315(g)(10)(i). We also propose to clarify in § 170.315(g)(10)(i) which app types are currently required to be supported for functional registration (confidential and public apps). Clarifying these app types required for functional registration does not introduce new requirements since confidential and public apps were already required to be supported for functional registration according to the current requirements in § 170.315(g)(10)(iii). We note that we propose to no longer specifically reference the “confidential app” profile from the SMART App Launch implementation guide in the § 170.315(g)(10) certification criterion. Instead, we propose to refer to the app types of “confidential app” and “public app” as described in the section of this rule titled “SMART App Launch 2.2.” In addition to this move and clarification, we also propose that on and after January 1, 2028, both the capabilities proposed in § 170.315(g)(10)(i)(A) and (B) would be required to support the full scope of API capabilities required in the § 170.315(g)(10) certification criterion. This includes as part of the regulation text reordering new proposed language in § 170.315(g)(10)(i)(A) to reference § 170.315(j)(1) to support “functional registration” and new proposed language in § 170.315(g)(10)(i)(B) to reference § 170.315(j)(2) to support “dynamic registration.” We clarify that the capability described at proposed § 170.315(g)(10)(i)(A) is not intended to substantively change the application registration requirements with which health IT developers are currently familiar, but instead clarify the nature of the functional requirements and detail which app types are required to be supported for functional registration (confidential and public apps). To accommodate the distinct proposal to require dynamic client registration as part of § 170.315(g)(10), the proposed § 170.315(g)(10)(i)(B) focuses on dynamic client registration for patient and user access as proposed in § 170.315(g)(10)(ii) and system access at (iii).</P>
                    <HD SOURCE="HD3">b. Proposed Revisions for Patient and User Access</HD>
                    <P>
                        In the context of retrieving data for a single patient, we propose to restructure and rephrase the data response requirements currently in § 170.315(g)(10)(i)(A), supported search operations requirements in § 170.315(g)(10)(ii)(A), secure connection requirements in § 170.315(g)(10)(iv)(A), authentication and authorization for patient and user scopes requirements in § 170.315(g)(10)(v)(A), and patient authorization revocation requirements in § 170.315(g)(10)(vi). We propose reorganizing those requirements to all be under proposed § 170.315(g)(10)(ii) to make clear which requirements support data retrieval for a single patient's data. Specifically, we propose to rename § 170.315(g)(10)(ii) to be “
                        <E T="03">Patient and user access</E>
                        ” and include these paragraphs as follows.
                    </P>
                    <P>
                        We propose to revise the paragraph in § 170.315(g)(10)(ii)(A) and add subparagraphs in § 170.315(g)(10)(ii)(A)(
                        <E T="03">1</E>
                        ) and (
                        <E T="03">2</E>
                        ) to include, with revisions, the requirements for secure connection currently in § 170.315(g)(10)(iv)(A), authentication and authorization for patient and user scopes currently under § 170.315(g)(10)(v)(A), and patient authorization revocation requirements currently in § 170.315(g)(10)(vi). We also propose to add a multi-factor authentication requirement in § 170.315(g)(10)(ii)(A)(
                        <E T="03">1</E>
                        )(
                        <E T="03">iii</E>
                        ) for patient-facing uses. The specific alignment between current regulatory text paragraphs and proposed new paragraphs is detailed in each of the bullets that follow.
                    </P>
                    <P>
                        • Proposed § 170.315(g)(10)(ii)(A)(
                        <E T="03">1</E>
                        )(
                        <E T="03">i</E>
                        ), § 170.315(g)(10)(ii)(A)(
                        <E T="03">2</E>
                        )(
                        <E T="03">i</E>
                        ), and § 170.315(g)(10)(ii)(B)(
                        <E T="03">1</E>
                        ) maintain the existing requirement in § 170.315(g)(10)(iv)(A) to support a secure connection and authentication and authorization for apps requesting patient and user scopes according to the SMART App Launch and US Core implementation guides. We propose to no longer explicitly mention “secure connection” since we believe it is redundant as the referenced implementation guides already include such requirements for secure connections. The “App Protection” section of the SMART App Launch IG requires the use of secure TLS connections and is required as part of the requirements at proposed § 170.315(g)(10)(ii)(A)(
                        <E T="03">1</E>
                        )(
                        <E T="03">i</E>
                        ) and § 170.315(g)(10)(ii)(A)(
                        <E T="03">2</E>
                        )(
                        <E T="03">i</E>
                        ) by reference to proposed § 170.315(j)(9) and § 170.315(j)(10)(i) respectively. Proposed § 170.315(j)(9) and § 170.315(j)(10)(i) require support for authorization according to capabilities from one of the SMART App Launch IGs adopted in § 170.215(c), which in turn necessitates the use of secure TLS connections as required in the “App Protection” section of the SMART App Launch IG. Additionally, the “Security” section of the US Core IG requires the use of secure TLS connections and is required as part of the requirements at proposed § 170.315(g)(10)(ii)(B)(
                        <E T="03">1</E>
                        ). Proposed § 170.315(g)(10)(ii)(B)(
                        <E T="03">1</E>
                        ) requires support for responding to requests for patient data according to the one of the US Core IGs adopted in § 170.215(b)(1), which in turn necessitates the use of secure TLS connections as required in the “Security” section of the US Core IG.
                    </P>
                    <P>
                        • We propose to revise the organization of authentication and authorization requirements for patient-facing apps and use-facing apps for § 170.315(g)(10) to be under § 170.315(g)(10)(ii)(A). We propose authentication and authorization requirements for patient access to be under § 170.315(g)(10)(ii)(A)(
                        <E T="03">1</E>
                        ) and authentication and authorization requirements for user access be under 
                        <PRTPAGE P="63577"/>
                        § 170.315(g)(10)(ii)(A)(
                        <E T="03">2</E>
                        ). The proposed revisions in § 170.315(g)(10)(ii)(A)(
                        <E T="03">1</E>
                        )(
                        <E T="03">i</E>
                        ) and § 170.315(g)(10)(ii)(A)(
                        <E T="03">2</E>
                        )(
                        <E T="03">i</E>
                        ) maintain the requirements currently in § 170.315(g)(10)(v)(A) for authentication and authorization for patient and user scopes (scopes being information access permissions as represented in the OAuth 2.0 Authorization Framework) according to SMART App Launch capabilities as currently referenced in § 170.215(c) and OpenID Connect Core as currently referenced in § 170.215(e). The proposed revisions in § 170.315(g)(10)(ii)(A)(
                        <E T="03">1</E>
                        )(
                        <E T="03">i</E>
                        ) reference the proposed certification criterion in § 170.315(j)(9) “SMART patient access for standalone apps,” which requires the SMART App Launch capabilities that are currently required to be supported for authentication and authorization of patient-facing apps. The proposed revisions in § 170.315(g)(10)(ii)(A)(
                        <E T="03">2</E>
                        )(
                        <E T="03">i</E>
                        ) reference the proposed certification criterion in § 170.315(j)(10) “SMART clinician access for EHR launch,” which requires the SMART App Launch capabilities currently required for authentication and authorization of user-facing apps. Current OpenID Connect Core requirements would also be maintained by the proposed references to § 170.315(j)(9) “SMART patient access for standalone apps” and (10) “SMART clinician access for EHR launch” since those proposed certification criteria require the “sso-openid-connect” SMART App Launch capability by requiring the “Single Sign-on” section of one of the SMART App Launch IGs adopted in § 170.215(c). In addition to maintaining current requirements from § 170.315(g)(10)(v)(A) for authentication and authorization for patient and user scopes, the proposed references in the § 170.315(g)(10) certification criterion to § 170.315(j)(9) and (10) would also add requirements to support SMART App Launch capabilities for authentication and authorization for patient-facing apps and user-facing apps according to the implementation specification of SMART App Launch 2.2.0, proposed in this rule to be adopted in § 170.215(c)(3). The proposed certification criteria in § 170.315(j)(9) and (10) would also include conformance dates for each set of required SMART capabilities. Conformance to each set of required SMART capabilities would be in alignment with the following: (1) expiration of SMART App Launch 1.0.0, adopted in § 170.215(c)(1), for use in the Program on January 1, 2026 as finalized in the HTI-1 Final Rule (89 FR 1292); (2) the proposed expiration of SMART App Launch 2.0.0, adopted in § 170.215(c)(2), for use in the Program on January 1, 2028; and (3) the proposed adoption of SMART App Launch 2.2.0 in § 170.215(c)(3). Please see the section titled “SMART App Launch 2.2” of this rule for additional details regarding the proposed expiration and adoption of SMART App Launch 2.0.0 and 2.2.0 respectively. For more information regarding how SMART App Launch capabilities as currently required and proposed to be required correspond to the proposed certification criteria in § 170.315(j)(9) and (10), including specific capabilities and their conformance dates, please refer to section III.B.16 “New Certification Criteria for Modular API Capabilities.”
                    </P>
                    <P>
                        • The requirements currently in § 170.315(g)(10)(v)(A)(
                        <E T="03">1</E>
                        )(
                        <E T="03">ii</E>
                        ), § 170.315(g)(10)(v)(A)(
                        <E T="03">1</E>
                        )(
                        <E T="03">iii</E>
                        ), and § 170.315(g)(10)(v)(A)(
                        <E T="03">2</E>
                        ) regarding the issuance of refresh tokens are mirrored in the proposed paragraphs in § 170.315(g)(10)(ii)(A)(
                        <E T="03">1</E>
                        )(
                        <E T="03">i</E>
                        ) and (
                        <E T="03">2</E>
                        )(
                        <E T="03">ii</E>
                        ) via cross references to the certification criteria proposed in § 170.315(j)(9) “SMART patient access for standalone apps” and (10) “SMART clinician access for EHR launch” respectively, which reference the proposed certification criterion in § 170.315(j)(6) “SMART App Launch user authorization,” wherein the language has been simplified to consolidate existing refresh token requirements and remove extraneous references to refresh token requirements already included in referenced implementation guides. Additionally, we include the authentication and authorization requirements that are currently in § 170.315(g)(10)(ii)(A)(
                        <E T="03">1</E>
                        )(
                        <E T="03">i</E>
                        ) and (
                        <E T="03">ii</E>
                        ) in our proposals in § 170.315(g)(10)(ii)(A)(
                        <E T="03">1</E>
                        ) “Authentication and authorization for patient access” and (
                        <E T="03">2</E>
                        ) “Authentication and authorization for user access,” which reference the proposed criteria at § 170.315(j)(9) “SMART patient access for standalone apps” and (10) “SMART clinician access for EHR launch,” which both reference the proposed certification criterion in § 170.315(j)(6) “SMART App Launch user authorization.” We reiterate the existing conformance expectations established in the COVID-19 Public Health Emergency Interim Final Rule (85 FR 70076) that health IT developers can determine the method(s) they use to support interactions with native apps and that health IT developers are not required to support all methods that third-party application developers seek to use. Further, we propose to revise the requirements that enable persistent access to confidential apps on subsequent connections which are currently required in § 170.315(g)(10)(v)(A
                        <E T="03">)</E>
                        (
                        <E T="03">2</E>
                        )(
                        <E T="03">ii</E>
                        ) to instead require support for a user to enable for confidential apps persistent access to patient information without requiring user re-authentication or re-authorization until authorization revocation at the user's direction. Additionally, we propose moving this requirement to part of one of the modular API capabilities in (j), specifically in § 170.315(j)(6)(iii). As proposed, § 170.315(j)(6)(iii) is referenced by the proposed certification criteria in § 170.315(j)(9) “SMART patient access for standalone apps” and (10) “SMART clinician access for EHR launch,” which are referenced by the proposed revised certification criterion in § 170.315(g)(10). Revising the requirement in this manner is intended to provide developers more flexibility in implementing persistent access for confidential apps while maintaining the requirement that patients and users can authorize persistent access to patient data to confidential apps until revoking that access.
                    </P>
                    <P>
                        • We propose to move the current “patient authorization revocation” requirement in § 170.315(g)(10)(vi) to § 170.315(j)(6) “SMART App Launch user authorization,” specifically § 170.315(j)(6)(iv) “User authorization revocation.” These requirements are referenced by the proposed certification criterion in § 170.315(j)(9) “SMART patient access for standalone apps” which is referenced by the proposed revised certification criterion in § 170.315(g)(10)(ii)(A)(
                        <E T="03">1</E>
                        )(
                        <E T="03">i</E>
                        ). We propose a new requirement to require support for user authorization revocation in § 170.315(g)(10)(ii)(A)(
                        <E T="03">2</E>
                        )(
                        <E T="03">i</E>
                        ) which references the requirements at the proposed certification criterion in § 170.315(j)(10)(ii), and is proposed to take effect on and after January 1, 2028. This would require a Health IT Module's authorization server to be able to revoke and must revoke an authorized application's access at a user's direction within 1 hour of the request. This is distinct from the existing patient authorization revocation requirement currently in § 170.315(g)(10)(vi) and proposed in § 170.315(j)(6)(iii) which requires support for revocation of a patient's authorization but does not require support for revocation of a clinician's authorization. We propose introducing this requirement in § 170.315(g)(10)(ii)(A)(
                        <E T="03">2</E>
                        )(
                        <E T="03">i</E>
                        ) to support revocation of clinician authorizations to enable clinicians to have greater control 
                        <PRTPAGE P="63578"/>
                        over their authorizations for applications to access patient data.
                    </P>
                    <P>
                        • We propose new requirements for authentication for dynamically registered patient-facing and user-facing apps in § 170.315(g)(10)(ii)(A)(
                        <E T="03">1</E>
                        )(
                        <E T="03">ii</E>
                        ) and (
                        <E T="03">2</E>
                        )(
                        <E T="03">ii</E>
                        ) respectively, with a compliance date on and after January 1, 2028. We refer readers to the “Revision of Standardized API for Patient and Population Services to Support Dynamic Client Registration” in section III.B.15.c of this proposed rule for additional details of the proposed § 170.315(g)(10) requirements for authentication and authorization of dynamically registered patient-facing apps and dynamically registered user-facing apps.
                    </P>
                    <P>
                        • The proposed revisions in § 170.315(g)(10)(ii)(A)(
                        <E T="03">1</E>
                        )(
                        <E T="03">iii</E>
                        ) would require multi-factor authentication to be supported for patient-facing authentication on and after January 1, 2028, according to the requirements specified in the proposal at § 170.315(d)(13)(ii). We believe this update aligns with industry information security best practices, and that it is necessary to help better protect electronic health information. See the proposal for updating § 170.315(d)(13) and referencing § 170.315(d)(13)(ii) across certain certification criteria with authentication use cases at section III.B.17.
                    </P>
                    <P>We propose to reorganize as part of § 170.315(g)(10)(ii)(B) the text for the current requirements for single patient data response currently in § 170.315(g)(10)(i)(A) and single patient supported search operations requirements currently in § 170.315(g)(10)(ii)(A), with proposed subparagraphs as follows:</P>
                    <P>
                        • The proposed language in § 170.315(g)(10)(ii)(B)(
                        <E T="03">1</E>
                        ) maintains the existing requirements for data response and search support but simplifies the language by consolidating references to implementation guides. As part of our revisions, we propose to no longer explicitly mention the requirement in the API certification criteria language regarding “mandatory” and “must support” because this was done for emphasis in our prior rulemaking and, we believe, consistent with long standing Program policy, that when we adopt standards and implementation specifications that all requirement aspects of those need to be addressed for conformance purposes. Additionally, to reflect our policy interests to advance imaging availability as described in section III.B.6, we propose to also include support for imaging links in § 170.315(g)(10)(ii)(B)(
                        <E T="03">1</E>
                        ) indicating that imaging links must be supported as part of data response and search requirements on and after January 1, 2028.
                    </P>
                    <P>
                        • We also propose in § 170.315(g)(10)(ii)(B)(
                        <E T="03">2</E>
                        ) that on and after January 1, 2028, support for the issuance of verifiable health records as specified by the requirements in proposed § 170.315(j)(22) be supported. We propose requiring support for verifiable health records in § 170.315(g)(10)(ii)(B)(
                        <E T="03">2</E>
                        ) to support the ability for patients to access their immunization and infectious disease-related laboratory test information in a format that is easily portable and verifiable by third parties, which is the underlying benefit of the SMART Health Card standard proposed as part of § 170.315(j)(22).
                    </P>
                    <P>
                        • Proposed § 170.315(g)(10)(ii)(B)(
                        <E T="03">3</E>
                        ) requires on and after January 1, 2028, support for subscriptions as a server for patient-facing apps and user-facing apps according to the requirements specified in § 170.315(j)(23). We refer readers to subsequent section III.B.19.e for additional details about this proposal.
                    </P>
                    <HD SOURCE="HD3">c. Proposed Revisions for System Access</HD>
                    <P>
                        We propose reorganizing under § 170.315(g)(10)(iii) the data response requirements currently in § 170.315(g)(10)(i)(B), supported search operations requirements currently in § 170.315(g)(10)(ii)(B), secure connection requirements in § 170.315(g)(10)(iv)(B), and authentication and authorization for system scopes requirements currently in § 170.315(g)(10)(v)(B). We believe these proposals will make it more efficient to understand the requirements necessary to support data retrieval for multiple patients' data. Specifically, we propose to revise § 170.315(g)(10)(iii) to be called “
                        <E T="03">System access</E>
                        ” and include the following paragraphs.
                    </P>
                    <P>
                        • We propose to organize authentication and authorization requirements for system access under the paragraph in § 170.315(g)(10)(iii)(A). We propose to add a paragraph in § 170.315(g)(10)(iii)(A)(
                        <E T="03">1</E>
                        ) which, by reference to the proposed certification criterion in § 170.315(j)(7), maintains requirements for secure connection currently in § 170.315(g)(10)(iv)(B) and authentication and authorization for system scopes in accordance with the “SMART Backend Services: Authorization Guide” currently in § 170.315(g)(10)(v)(B). We do not include specific mention of “secure connection” in the proposed paragraphs in § 170.315(g)(10)(iii)(A)(
                        <E T="03">1</E>
                        ) or § 170.315(j)(7) since we believe it is redundant as the referenced implementation guides already include such requirements for secure connections. The proposed paragraph in § 170.315(g)(10)(iii)(A)(
                        <E T="03">1</E>
                        ) maintains the existing system authentication and authorization requirements currently in § 170.315(g)(10)(v)(B) by referencing the proposed § 170.315(j)(7) certification criterion. Proposing to require conformance to the proposed § 170.315(j)(7) certification criterion maintains the requirements for SMART Backend Services while using consistent language across API certification criteria in the Program. The § 170.315(j)(7) certification criterion also facilitates reference to the updated location of the SMART Backend Services specification, which has been moved from the Bulk Data Access guide to the SMART App Launch guide in subsequent versions of those guides. We also propose to include language in § 170.315(g)(10)(iii)(A)(
                        <E T="03">1</E>
                        ) which clarifies that authentication and authorization for system access in accordance with SMART Backend Services is only required for functionally registered system apps.
                    </P>
                    <P>
                        • Proposed § 170.315(g)(10)(iii)(A)(
                        <E T="03">2</E>
                        ) would support the dynamic registration proposal described in section III.B.15.c of this proposed rule to support authentication and authorization of dynamically registered system apps. The paragraph in § 170.315(g)(10)(iii)(A)(
                        <E T="03">2</E>
                        ) describes the new proposed requirements to support authentication and authorization for dynamically registered system apps according to the “Business-to-Business” section of the UDAP Security IG v1 proposed in § 170.215(o) and proposes that a Health IT Module certifying to § 170.315(g)(10) must support the specified sections of the UDAP Security IG v1 on and after January 1, 2028 for system apps dynamically registered using the capabilities in proposed § 170.315(g)(10)(i)(B). We refer readers to the “Revision of Standardized API for Patient and Population Services to Support Dynamic Client Registration” in section III.B.15.c of this proposed rule for additional details of the proposed § 170.315(g)(10) requirements for authentication and authorization of dynamically registered system apps.
                    </P>
                    <P>
                        • We propose to organize system information access requirements under proposed paragraph § 170.315(g)(10)(iii)(B). We propose to maintain the data response requirements currently in § 170.315(g)(10)(i)(B) and include those requirements in proposed § 170.315(g)(10)(iii)(B)(
                        <E T="03">2</E>
                        ) and (
                        <E T="03">i</E>
                        ). We note that the existing supported search operations requirements at current § 170.315(g)(10)(ii)(B) are not applicable 
                        <PRTPAGE P="63579"/>
                        to the export of multiple patients' data according to the Bulk Data Access implementation guide adopted under § 170.215(d), since search requests are not distinct from the data export requests as defined in that guide. As a result, we propose to remove the existing requirements language currently in § 170.315(g)(10)(ii)(B) but do not anticipate any change to the substance of the § 170.315(g)(10) certification criterion requirements given such requirements are subsumed by the data response requirements proposed in § 170.315(g)(10)(iii)(B)(
                        <E T="03">2</E>
                        ) and (
                        <E T="03">i</E>
                        ). The proposed language in § 170.315(g)(10)(iii)(B)(
                        <E T="03">2</E>
                        ) and (
                        <E T="03">i</E>
                        ) maintains the existing requirements for data response but simplifies the language by removing redundant language for requirements already required through reference to implementation guides and thus as we noted above, we have removed the explicit reference to “mandatory” and “must support” in this revised paragraph. Additionally, to reflect our policy interests to advance imaging availability as described in section III.B.6, we propose to also include support for imaging links in § 170.315(g)(10)(iii)(B)(
                        <E T="03">2</E>
                        ) and (
                        <E T="03">i</E>
                        ) indicating that imaging links must be supported as part of data response requirements for multiple patients on and after January 1, 2028. The requirements as proposed at and under § 170.315(g)(10)(iii)(B)(
                        <E T="03">2</E>
                        ) are rephrased such that the Bulk Data Access implementation guide features required for the § 170.315(g)(10) certification criterion (
                        <E T="03">e.g.,</E>
                         group export) are explicitly enumerated in the criterion instead of in the reference to Bulk Data Access implementation guide in § 170.215(d). Also, to accommodate the distinct proposal to support the “_type” query parameter in § 170.315(g)(10) described in section III.B.14 of this rule, we propose adding paragraph § 170.315(g)(10)(iii)(B)(
                        <E T="03">2</E>
                        )(
                        <E T="03">ii</E>
                        ) indicating that parameter must be supported. Both the “_type” query parameter and use of the parameter to support bulk data retrieval of imaging links would need to be supported on and after January 1, 2028.We propose that the paragraph in § 170.315(g)(10)(iii)(B)(
                        <E T="03">1</E>
                        ) requires support to respond to requests from system apps for patient data consistent with the search criteria included in the FHIR standard adopted in § 170.215(b) and one of the US Core IGs as adopted in § 170.215(b)(1) for each of the data classes and data elements included in at least one of the versions of the USCDI standard adopted in § 170.213 and, on and after January 1, 2028, imaging links. We refer readers to subsequent section III.B.19.e for additional details about this proposal. Proposed § 170.315(g)(10)(iii)(B)(
                        <E T="03">3</E>
                        ) requires on and after January 1, 2028, support for subscriptions as a server for system apps according to the requirements specified in § 170.315(j)(23). We refer readers to subsequent section III.B.19.e for additional details about this proposal.
                    </P>
                    <HD SOURCE="HD3">d. Other Restructured Requirements</HD>
                    <P>
                        We propose to continue to require the token introspection requirements currently in § 170.315(g)(10)(vii) by moving such requirements language to the proposed § 170.315(j)(6) and (7) API certification criteria, and then referencing those criteria directly or indirectly where appropriate in the § 170.315(g)(10) certification criterion. The existing token introspection requirements apply to tokens issued for both patient and user scopes, and system scopes. Thus, we propose in § 170.315(g)(10)(ii)(A)(
                        <E T="03">1</E>
                        )(
                        <E T="03">i</E>
                        ) to continue to require token introspection for tokens issued to patient-facing apps by referencing § 170.315(j)(9), which references § 170.315(j)(6). Next, we propose in § 170.315(g)(10)(ii)(A)(
                        <E T="03">2</E>
                        )(
                        <E T="03">i</E>
                        ) to continue to require token introspection for user-facing apps by referencing § 170.315(j)(10), which references § 170.315(j)(6). Next, we propose in § 170.315(g)(10)(iii)(A)(
                        <E T="03">1</E>
                        ) to continue to require token introspection for system apps by referencing § 170.315(j)(7). Furthermore, we propose a new requirement in § 170.315(g)(10)(iii)(A)(
                        <E T="03">2</E>
                        ), by requiring conformance to § 170.315(j)(8) on and after January 1, 2028, to require token introspection according to the SMART App Launch implementation guide for dynamically registered system apps on and after January 1, 2028.
                    </P>
                    <P>Lastly, we propose to move the API documentation requirements currently required in § 170.315(g)(10)(viii) to the API Conditions and Maintenance of Certification requirements in § 170.404(a)(2)(i), which would result in this paragraph no longer being part of § 170.315(g)(10) as part of the overall revision to this certification criterion. We do not intend to introduce new documentation requirements for the § 170.315(g)(10) certification criterion with this proposal. Instead, the goal of this proposal is to consolidate API documentation requirements across the Program where possible as described in additional detail in section III.B.20.d. We seek comment on the proposed revisions we have discussed for § 170.315(g)(10).</P>
                    <HD SOURCE="HD3">e. Proposed Requirements for System Read and Search API, Subscriptions, and Workflow Triggers for Decision Support Interventions</HD>
                    <P>
                        We propose several new requirements for the Standardized API for Patient and Population Services certification criterion in § 170.315(g)(10) to support enhanced interoperability and advanced workflows to overall reduce developer burden and barriers to accessing and utilizing patient health information. We propose support for a “Read and search API” for system access in § 170.315(g)(10)(iii)(B)(
                        <E T="03">1</E>
                        ), HL7 FHIR subscriptions for patient and user access in § 170.315(g)(10)(ii)(B)(
                        <E T="03">3</E>
                        ) and system access in § 170.315(g)(10)(iii)(B)(
                        <E T="03">3</E>
                        ), and workflow triggers for decision support interventions in § 170.315(g)(10)(iv), as described further below.
                    </P>
                    <P>
                        We previously only required Health IT Modules certified to § 170.315(g)(10) to support the “Bulk FHIR API” for system access, and only required the US Core IG read and search capabilities for patient and user scopes. We propose to include a read and search API according to the “US Core Server CapabilityStatement” for each of the data classes and data elements included in at least one of the versions of the USCDI standard adopted in § 170.213 in § 170.315(g)(10)(iii)(B)(
                        <E T="03">1</E>
                        ) in order to explicitly require that certified Health IT Modules support system applications to perform read and search operations for patient health information using a standardized API. The proposal includes optional support for imaging links requests as of the effective date of the rule. On and after January 1, 2028, requests for imaging links must be supported.
                    </P>
                    <P>
                        We propose support for HL7 FHIR subscriptions as part of the Standardized API for Patient and Population Services for patient and user access in § 170.315(g)(10)(ii)(B)(
                        <E T="03">3</E>
                        ) and for system access in § 170.315(g)(10)(iii)(B)(
                        <E T="03">3</E>
                        ). The proposals require Health IT Modules to support subscriptions as a server according to the requirements specified in § 170.315(j)(23), which includes several infrastructure capabilities to support HL7 FHIR Subscriptions and a list of HL7 FHIR Resources that must be supported for subscription notifications and accompanying data elements that must be supported for subscription filtering. The proposed certification criterion in § 170.315(j)(23) is discussed further in this rule in section III.B.15.b.iii.
                    </P>
                    <P>
                        We propose to require support for workflow triggers for decision support interventions under proposed 
                        <PRTPAGE P="63580"/>
                        § 170.315(g)(10)(iv). We propose that the Health IT Module must support capabilities in § 170.315(j)(20) (where we have proposed to adopt the “workflow triggers for decision support interventions” certification criterion) to enable workflow triggers to call decision support services, including support for “patient-view” and “order-sign” CDS Hooks according to at least one of the versions of the implementation specification adopted in § 170.215(f)(1). We propose support for “patient-view” and “order-sign” because these CDS Hooks are at maturity level “5—Mature” according to the CDS Hooks IG and can be used to support a wide variety of workflow processes. We further clarify and propose in 170.315(g)(10)(iv) that developers may support workflow triggers for decision support interventions for the time period up to and including December 31, 2027 and must support workflow triggers for decision support interventions on and after January 1, 2028.
                    </P>
                    <HD SOURCE="HD3">20. Patient, Provider, and Payer APIs</HD>
                    <P>In this section, we propose to adopt a set of certification criteria in § 170.315(g)(30)-(36) to support data exchange between health care payers, providers, and patients. These proposed certification criteria would enable the exchange of data including clinical and coverage information, drug formulary information, and prior authorization information, between patients, providers, and payers as appropriate to each exchange. These proposed certification criteria are based on a series of recent policies finalized by CMS which we describe in detail in the following section. If finalized, these certification criteria would be available for health IT developers (which may include payers and other developers providing technology to payers) seeking voluntary certification for health IT products supporting these use cases.</P>
                    <HD SOURCE="HD3">a. Background on CMS Interoperability Rulemaking</HD>
                    <P>
                        On May 1, 2020, the “Medicare and Medicaid Programs; Patient Protection and Affordable Care Act; Interoperability and Patient Access for Medicare Advantage (MA) Organization and Medicaid Managed Care Plans, State Medicaid Agencies, CHIP Agencies and CHIP Managed Care Entities, Issuers of Qualified Health Plans on the Federally-Facilitated Exchanges, and Health Care Providers” final rule (85 FR 25510) was published in the 
                        <E T="04">Federal Register</E>
                         (hereinafter referred to as the “CMS Interoperability and Patient Access Final Rule”). CMS required impacted payers 
                        <SU>184</SU>
                        <FTREF/>
                         to implement and maintain a FHIR-based Patient Access API to allow patients, through the health application of their choice, to easily access their claims and encounter information as well as clinical data, including laboratory results, and provider remittances and enrollee cost-sharing pertaining to such claims, if maintained by the impacted payer (85 FR 25559). CMS also required impacted payers to implement a Provider Directory API to make available information such as contracted provider names, addresses, and phone numbers (85 FR 25563).
                    </P>
                    <FTNT>
                        <P>
                            <SU>184</SU>
                             For the purposes of the CMS Interoperability and Patient Access and Interoperability and Prior Authorization Final Rules discussed in this section, impacted payers include Medicare Advantage (MA) organizations, state Medicaid fee-for-service (FFS) programs, state Children's Health Insurance Program (CHIP) FFS programs, Medicaid managed care plans, CHIP managed care entities, and Qualified Health Plan (QHP) issuers on the Federally-facilitated Exchanges (FFEs).
                        </P>
                    </FTNT>
                    <P>
                        On February 8, 2024, the “Medicare and Medicaid Programs; Patient Protection and Affordable Care Act; Advancing Interoperability and Improving Prior Authorization Processes for Medicare Advantage Organizations, Medicaid Managed Care Plans, State Medicaid Agencies, Children's Health Insurance Program (CHIP) Agencies and CHIP Managed Care Entities, Issuers of Qualified Health Plans on the Federally-Facilitated Exchanges, Merit-Based Incentive Payment System (MIPS) Eligible Clinicians, and Eligible Hospitals and Critical Access Hospitals in the Medicare Promoting Interoperability Program” (CMS Interoperability and Prior Authorization Final Rule) was published in the 
                        <E T="04">Federal Register</E>
                         (89 FR 8758). Final policies in this rule included: expanding the content available via the existing Patient Access API to include information about prior authorizations; requiring impacted payers to implement and maintain a Provider Access API to make patient data available to in-network providers with whom the patient has a treatment relationship; and requiring impacted payers build and maintain a Payer-to-Payer API to exchange patient data when a patient moves between payers or has concurrent payers. CMS also required impacted payers to implement and maintain a Prior Authorization API to facilitate electronic prior authorization processes. Finally, the rule added electronic prior authorization measures to the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability performance category.
                    </P>
                    <P>In the CMS Interoperability and Patient Access Final Rule (85 FR 25510 through 25640) and the CMS Interoperability and Prior Authorization Final Rule (89 FR 8758 through 8988), CMS requires impacted payers to use certain standards and implementation guides which ONC has adopted in § 170.215, as well as the USCDI standard in § 170.213. Specifically, CMS has finalized technical requirements for the following APIs: Patient Access API (85 FR 25558 through 25559, 89 FR 8784 through 8787), Provider Access API (89 FR 8817 through 8820), Payer-to-Payer API (89 FR 8855 through 8856), Prior Authorization API (89 FR 8897 through 8901), and the Provider Directory API (85 FR 25563 through 25564). In the CMS Interoperability and Prior Authorization Final Rule, CMS also recommended a number of implementation guides that may be used to support effective implementation of the required payer APIs (89 FR 8945).</P>
                    <HD SOURCE="HD3">b. Proposal Overview</HD>
                    <P>We propose certification criteria below in § 170.315(g)(30)-(36) for Health IT Modules that can be used to support more effective exchange of clinical, coverage, and prior authorization information. The proposed certification criteria, if finalized, would support the availability of health IT that can enable payers and health care providers to meet requirements established in the Interoperability and Patient Access Final Rule (85 FR 25522 through 25569) and the Interoperability and Prior Authorization Final Rule (89 FR 8768 through 8946). As part of the proposals below, we include further discussion of how each proposed certification criterion would support the availability of information and enable functionality CMS has identified as part of corresponding requirements. We intend to continue to work with CMS in the future to ensure Health IT Modules certified to the proposed criteria in § 170.315(g)(30)-(36) enable efficient and effective support for CMS policies.</P>
                    <P>
                        In general, we believe that use of technology meeting these certification criteria would help to enable exchange of information that promotes a more effective marketplace, increases competition, and provides benefits to patients, including: increased consumer choice, improved outcomes in healthcare services, and more robust care coordination through improved availability and exchange of health care provider information. Increased electronic exchange and automation of such information, as supported by the proposed certification criteria, would 
                        <PRTPAGE P="63581"/>
                        enable patients to better manage their own care, allow providers to make more timely and informed treatment decisions, and reduce costs for both payers and providers by reducing the amount of manual intervention required in the exchange and authorization processes addressed by the proposed certification criteria.
                    </P>
                    <P>
                        These proposed certification criteria reference a set of API implementation specifications that ONC proposes to adopt, on behalf of the Secretary, in § 170.215(j), (k), (m), and (n).
                        <SU>185</SU>
                        <FTREF/>
                         These specifications are based upon HL7® FHIR® R4. In concert with CMS, ONC has led or participated in a variety of activities related to monitoring and evaluating the standards and implementation specifications identified in this proposed rule, utilizing available mechanisms for gathering input on these standards from stakeholders and experts. Several of these proposed implementation specifications were developed by the HL7® Da Vinci Project.
                        <SU>186</SU>
                        <FTREF/>
                         The Da Vinci Project is a private sector initiative that brings together payers, health IT developers, providers, and other public participants to facilitate the definition, design, and creation of use case specific reference implementations of solutions based upon the HL7 FHIR platform that involve managing and sharing clinical and administrative data between industry partners. Because the Da Vinci Project is aligned with HL7, solutions developed through the project may become industry standards. The Da Vinci Project's use case requirements, test scenarios, and test data, as well as the resulting implementation guides and reference implementations, are available without licensing requirements.
                    </P>
                    <FTNT>
                        <P>
                            <SU>185</SU>
                             For a more detailed discussion of APIs generally, we refer readers to the Application Programming Interfaces Condition of Certification and Maintenance of Certification preamble language in the ONC Cures Act Final Rule at 85 FR 25739.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>186</SU>
                             For more information about the Da Vinci Project, please visit 
                            <E T="03">https://www.hl7.org/about/davinci/.</E>
                        </P>
                    </FTNT>
                    <P>The proposed implementation specifications referenced in the proposed certification criteria in § 170.315(g)(30)-(36) include the required and recommended implementation specifications identified in CMS' finalized policies for payer API requirements (89 FR 8945). We propose to adopt current versions of the IGs that CMS recommended in the CMS Interoperability and Prior Authorization Final Rule and propose to require these IGs as part of the certification criteria proposed in § 170.315(g)(30)-(36). In the CMS Interoperability and Prior Authorization Final Rule, CMS discussed its approach to recommending, rather than requiring, certain IGs for payer APIs. CMS stated that its goal in recommending the specific IGs for each API was to provide directional guidance to the industry without locking payers into the versions available at the time of the CMS Interoperability and Prior Authorization proposed rule, due to the maturity of the versions available at that time (89 FR 8921). CMS sought to ensure that payers could use subsequent versions of those IGs without being restricted to those versions. CMS further stated that it intended to monitor IG development and would consider proposing to require versions of these IGs in future rulemaking (89 FR 8937).</P>
                    <P>We believe that proposing to adopt the current versions of the IGs recommended by CMS in the rulemaking described above is appropriate for the proposed certification criteria at this time. Adopting and specifying use of these IGs is necessary to ensure that Health IT Modules certified to the criteria proposed in this section are implemented consistently and enable interoperable exchange of information. We also note that adoption of these IGs would support CMS policies established in their Interoperability and Prior Authorization Final Rule. Furthermore, if the adoption of these IGs is finalized, we would review and potentially approve future versions of these standards under the SVAP for voluntary use in the Program as they become available. The flexibility provided under the SVAP would ensure that developers are able to voluntarily update to later versions of these standards as future improvements are made, without waiting for updated versions to be proposed and finalized in regulation. In addition, we will continue to work with CMS to identify updated versions of these standards for potential future adoption in regulation at appropriate intervals so that the adopted versions of standards are the most up-to-date available and are feasible for real-world implementation.</P>
                    <P>The proposed certification criteria in § 170.315(g)(30)-(36) also incorporate certification criteria for modular API capabilities proposed in § 170.315(j) in section III.B.17 of this proposed rule, including capabilities for registration (§ 170.315(j)(1)-(2)), authentication and authorization (§ 170.315(j)(5)-(7)), workflow triggers for decision support interventions (§ 170.315(j)(20)-(21)), and subscriptions (§ 170.315(j)(23)-(24)).</P>
                    <P>Below, we describe each certification criterion and our intent to certify Health IT Modules to these certification criteria to support interoperability. However, we note that the certification of any Health IT Module by a health IT developer is voluntary. The proposals in this proposed rule would not establish requirements for health IT beyond those Health IT Modules submitted for certification for these criteria under the Program, nor does the availability of these certification criteria require any individual or entity to use certified health IT, including payers subject to the CMS requirements. Our goal in proposing these certification criteria and the related implementation specifications is to support health IT developers building these capabilities (and customers implementing them) in a manner that is consistent with nationally recognized standards and supports testing and conformance to these standards through the ONC Health IT Certification Program. ONC's adoption of certification criteria, standards, and implementation specifications are part of an effort to advance a set of minimum technical requirements, increase the availability of health IT leveraging such requirements, and provide the healthcare community with an improved, interoperable health IT infrastructure.</P>
                    <P>We reiterate that, if finalized, certification to these criteria would be available for health IT developers (which may include payers and other developers providing technology to payers) seeking voluntary certification and any requirements for a certification criterion are only required in the sense that they are necessary to achieve certification. ONC does not establish requirements for whether and in what ways patients, health care providers, payers or others use health IT. Instead, we enable the certification of Health IT Modules that may support a wide range of users. In this way, the Program helps to advance standards for certified Health IT Modules and increases the availability of interoperable health IT across healthcare and health related use cases.</P>
                    <P>
                        Finally, we note that CMS has not proposed to require that impacted payers subject to the API requirements in the CMS Patient Access and Interoperability and CMS Interoperability and Prior Authorization Final Rules obtain or implement Health IT Modules certified to the criteria in this proposed rule. We also note that CMS has not identified health IT certified to the “prior authorization API—provider” criterion proposed below in § 170.315(g)(34) as necessary to complete the finalized electronic prior 
                        <PRTPAGE P="63582"/>
                        authorization measures in the Medicare Promoting Interoperability Program and the Promoting Interoperability performance category of MIPS. If this certification criterion is finalized, we would work with CMS on appropriate updates to the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability performance category to identify health IT certified to this criterion as an element of CEHRT necessary to report on the electronic prior authorization measures. As CMS noted in the Interoperability and Prior Authorization Final Rule, use of health IT certified to support electronic prior authorization transactions can help to ensure that the actions associated with these measures are executed in a consistent fashion across the health care providers participating in these programs (89 FR 8802).
                    </P>
                    <HD SOURCE="HD3">c. Proposed Certification Criteria</HD>
                    <P>We propose to adopt the following new certification criteria for Patient, Provider, and Payer APIs:</P>
                    <HD SOURCE="HD3">i. Patient Access API (§ 170.315(g)(30))</HD>
                    <P>We propose to adopt a “patient access API” certification criterion in § 170.315(g)(30) to specify requirements for Health IT Modules that can enable patients to access their health and administrative information by using a health application of their choice. While many of the requirements introduced in the ONC Cures Act Final Rule (85 FR 25642) expanded patient access to clinical information contained within health IT, such as EHRs, broadening this electronic access to include coverage and payer information can help expand the information available to help patients with decision-making.</P>
                    <P>We propose in § 170.315(g)(30)(i) to require support for two registration pathways for a Health IT Module certified to the “patient access API” criterion: a functional registration pathway for applications that are unable to meet the requirements for dynamic registration and a dynamic registration pathway for applications that can support automated, scalable registration. We propose in § 170.315(g)(30)(i)(A) that the Health IT Module must support functional registration according to the requirements included in § 170.315(j)(1) whereby confidential and public apps can register using a non-standardized method. We propose in § 170.315(g)(30)(i)(B) to require the Health IT Module to support a dynamic registration pathway for confidential apps according to the requirements in § 170.315(j)(2).</P>
                    <P>We propose in § 170.315(g)(30)(ii) to require authentication and authorization for patient access. To enable patients to authorize access to patient data by functionally and dynamically registered apps, we propose in § 170.315(g)(30)(ii)(A) that the Health IT Module must support authentication and authorization according to the SMART App Launch IG during the process of granting access to patient data, according to the requirements in § 170.315(j)(9). To enable authentication of dynamically registered apps, we propose in § 170.315(g)(30)(ii)(B) that the Health IT Module must support asymmetric certificate-based authentication according to the requirements in § 170.315(j)(5) for patient-facing apps dynamically registered using the capabilities in § 170.315(g)(30)(i)(B). We refer readers to the proposals in sections III.B.16. (“New Certification Criteria for Modular API Capabilities”) and III.B.15. (“New Requirements to Support Dynamic Client Registration Protocol in the Program”) for more information about our proposed certification criteria in § 170.315(j) and proposal for dynamic registration respectively.</P>
                    <P>We propose later in this section that Certified API Developers with API technology certified to the criterion in § 170.315(g)(30) would need to adhere to the API Condition and Maintenance of Certification requirements proposed in § 170.404. This would mean that such developers would need to publish trust community information necessary for dynamic registration, as proposed in § 170.404(b)(2)(iii).</P>
                    <P>We propose in § 170.315(g)(30)(ii)(C) to require multi-factor authentication for patient-facing authentication on and after January 1, 2028, as proposed in § 170.315(d)(13)(ii) in section III.B.17. of this proposed rule. We believe this update is in line with industry information security best practice for an important authentication use case in health IT and that it is necessary to help better protect EHI.</P>
                    <P>
                        To make information available about a payer's list of preferred drugs, we propose in § 170.315(g)(30)(iii) that the Health IT Module must publish information regarding the payer's drug formulary information according to at least one of the versions of the implementation specification adopted in § 170.215(m), including the requirements described in the “US Drug Formulary Server Capability Statement.” We propose to adopt the HL7 FHIR® Da Vinci—Payer Data Exchange (PDex) US Drug Formulary Implementation Guide, Version 2.0.1—STU2 (PDex US Drug Formulary IG) 
                        <SU>187</SU>
                        <FTREF/>
                         in § 170.215(m)(1) and incorporate it by reference in § 170.299. We propose to adopt this implementation specification under PHSA section 3004 and make it available for HHS use. This implementation specification can enable consumers, members, and patients to understand the costs and alternatives for drugs that have been prescribed, and to compare their drug costs across different insurance plans. If we adopt subsequent versions of the PDex US Drug Formulary IG under the paragraph in § 170.215(m), our proposals that require the use of at least one of the versions of the implementation specification adopted in § 170.215(m) would enable health IT developers to use any version adopted at this location, unless we specify an “expiration” date which indicates a certain version of the specification may no longer be used after that date.
                    </P>
                    <FTNT>
                        <P>
                            <SU>187</SU>
                             
                            <E T="03">See https://hl7.org/fhir/us/davinci-drug-formulary/STU2.0.1/.</E>
                        </P>
                    </FTNT>
                    <P>To support the exchange of formulary data that is integrated with protected health information (PHI) or personally identifiable information (PII), such as enabling a payer to provide personalized information to the patient based on their medications, we propose in § 170.315(g)(30)(iii)(A) that the Health IT Module must provide support for the “Authenticated API” according to at least one of the versions of the implementation specification adopted in § 170.215(m) (where we have proposed to adopt the PDex US Drug Formulary IG Version 2.0.1—STU2) and the requirements proposed in § 170.315(g)(30)(i) and (ii) related to registration as well as authentication and authorization. To support the exchange of formulary data that is publicly available, and which does not contain PHI or PII, we propose in § 170.315(g)(30)(iii)(B) that the Health IT Module must provide support for an “Unauthenticated API” according to at least one of the versions of the implementation specification adopted in § 170.215(m).</P>
                    <P>
                        We propose in § 170.315(g)(30)(iv) requirements for a Health IT Module certified to the “patient access API” criterion to support access to patient health, coverage, and claims information. We propose in § 170.315(g)(30)(iv)(A) that the Health IT Module must allow patients to access and share clinical and coverage information via a standardized API(s) according to at least one of the versions of the implementation specification adopted in § 170.215(k)(2). Under this paragraph, in § 170.215(k)(2)(i), we propose to adopt the HL7 FHIR Da Vinci 
                        <PRTPAGE P="63583"/>
                        Payer Data Exchange (PDex) Implementation Guide Version 2.0.0—STU2 
                        <SU>188</SU>
                        <FTREF/>
                         and incorporate it by reference in § 170.299. We propose to adopt this implementation specification under PHSA section 3004 and make it available for HHS use. This implementation specification enables a payer to create a member's health history using clinical resources based on US Core profiles. If we adopt subsequent versions of the PDex IG in § 170.215(k)(2), our proposals that require use of at least one of the versions of the implementation specification adopted in § 170.215(k)(2) would enable health IT developers to use any version adopted at this location, unless we specify an “expiration” date which indicates a certain version of the specification may no longer be used after that date.
                    </P>
                    <FTNT>
                        <P>
                            <SU>188</SU>
                             
                            <E T="03">See https://hl7.org/fhir/us/davinci-pdex/STU2/.</E>
                        </P>
                    </FTNT>
                    <P>
                        We note that a version 2.1.0 of the PDex IG is currently under development and available for interested parties to review.
                        <SU>189</SU>
                        <FTREF/>
                         We propose as an alternative, to adopt PDex IG version 2.1.0 if the standard is balloted and published before the issuance of the HTI-2 Final Rule. We note several important enhancements to the PDex IG version 2.1.0 from 2.0.0—STU2 to align with the Interoperability and Patient Access Final Rule (85 FR 25522 through 25569) and the Interoperability and Prior Authorization Final Rule (89 FR 8768 through 8946). For example, version 2.1.0 supports US Core 6.1.0, which supports USCDI v3, as well as drops required support for aspects of prior authorization that are viewed as unnecessary or complicating to successful execution of the transaction in version 2.0.0 of the PDex IG. Version 2.1.0 also includes an important use case for bulk data access based on the finalization of the Bulk Data Access IG as a required standard under the Payer API requirements finalized in CMS' rules.
                    </P>
                    <FTNT>
                        <P>
                            <SU>189</SU>
                             
                            <E T="03">See https://build.fhir.org/ig/HL7/davinci-epdx/.</E>
                        </P>
                    </FTNT>
                    <P>We believe that continued alignment among industry, government, and standards development organizations involved with the payer data exchange use cases is necessary and we believe that if PDex IG version 2.1.0 is balloted and published before issuance of the HTI-2 Final Rule, adoption of version 2.1.0 would support such alignment.</P>
                    <P>
                        In order to enable patient access to information and allow patients to incorporate their data into apps or systems of their choice with minimal effort, we propose in § 170.315(g)(30)(iv)(A)(
                        <E T="03">1</E>
                        ) that the Health IT Module must support the ability for patients to authenticate and share information with an application, service, or health plan according to at least one of the versions of the implementation specification adopted in § 170.215(k)(2) (where we have proposed to adopt the PDex IG version 2.0.0—STU2). Specifically, we propose in § 170.315(g)(30)(iv)(A)(
                        <E T="03">1</E>
                        )(
                        <E T="03">i</E>
                        ) that the Health IT Module must support the requirements associated with the “OAuth2.0 or SMART-on-FHIR Member-authorized Exchange” exchange method, including the requirements in the section “OAuth and FHIR API.” We propose in § 170.315(g)(30)(iv)(A)(
                        <E T="03">1</E>
                        )(
                        <E T="03">ii</E>
                        ) that the Health IT Module must support the requirements included in the “PDEX Server CapabilityStatement” and the HL7 FHIR Profiles, Resources, and operations included in Section 4.5.4 “CapabilityStatement” 
                        <SU>190</SU>
                        <FTREF/>
                         according to at least one of the versions of the implementation specification adopted in § 170.215(k)(2) (where we have proposed to adopt the PDex IG version 2.0.0—STU2).
                    </P>
                    <FTNT>
                        <P>
                            <SU>190</SU>
                             For more information, 
                            <E T="03">see https://hl7.org/fhir/us/davinci-pdex/STU2/introduction.html#capabilitystatement.</E>
                        </P>
                    </FTNT>
                    <P>
                        Finally, in § 170.315(g)(30)(iv)(A)(
                        <E T="03">1</E>
                        )(
                        <E T="03">iii</E>
                        ) we propose that the Health IT Module must support the capabilities described in “US Core Server CapabilityStatement” according to at least one of the versions of the implementation specification adopted in § 170.215(b)(1) (where we have adopted US Core IG version 3.1.1, which expires on January 1, 2026, US Core IG version 6.1.0, which we propose will expire on January 1, 2028, and where we propose to adopt US Core IG version 7.0.0). We further propose that the Health IT Module must support the capabilities in “US Core Server CapabilityStatement” for each of the data classes and data elements included in at least one of the versions of the USCDI standard adopted in § 170.213 (where we have adopted USCDI version 1, which expires on January 1, 2026, USCDI version 3, which we propose will expire on January 1, 2028, and where we propose to adopt USCDI version 4). We note that while most of the USCDI and US Core requirements are met through the PDEX Server CapabilityStatement requirements in § 170.315(g)(30)(iv)(A)(
                        <E T="03">1</E>
                        )(
                        <E T="03">iii</E>
                        ), we have added this requirement to ensure the Health IT Module supports availability of all of the data classes and data elements in at least one of the versions of the USCDI adopted in § 170.213.
                    </P>
                    <P>We note that in section III.B.6 of this proposed rule, “New Imaging Requirements for Health IT Modules,” we propose to revise certification criteria for “transitions of care” in § 170.315(b)(1); “application access—all data request” in § 170.315(g)(9); and “standardized API for patient and population services” in § 170.315(g)(10) by adding new provisions to include support of a link to diagnostic imaging. The CMS API requirements for impacted payers, which we are seeking to support with the proposed certification criteria in § 170.315(g)(30)-(36), reference the versions of the USCDI available in § 170.213, which do not include imaging links as a data element at this time. Therefore, in order to maintain alignment with current CMS requirements for impacted payers, we have not proposed to separately require support for imaging links by a Health IT Module certified to the proposed certification criteria in § 170.315(g)(30), (32), and (33). We request comment on our decision to not propose to include imaging links, and whether interested parties believe a requirement to support imaging links, in a manner similar to the proposed requirements for the certification criteria mentioned above, would be appropriate and desirable for the proposed certification criteria in § 170.315(g)(30), (32), and (33).</P>
                    <P>
                        We propose in § 170.315(g)(30)(iv)(B) that the Health IT Module must allow patients to access their claims information via a standardized API(s) according to at least one of the versions of the implementation specification adopted in § 170.215(k)(1). In § 170.215(k)(1)(i), we propose, independent of the certification criterion proposal, to adopt the HL7 FHIR Consumer Directed Payer Data Exchange (CARIN IG for Blue Button®) Implementation Guide version 2.0.0—STU 2 
                        <SU>191</SU>
                        <FTREF/>
                         and incorporate it by reference in § 170.299. We propose to adopt this implementation specification under PHSA section 3004 and make it available for HHS use. This implementation specification supports providing a set of resources that payers can display to consumers, primarily financial (claims and encounter) data, with some limited associated clinical data. If we adopt subsequent versions of the CARIN IG for Blue Button® in § 170.215(k)(1), our proposals that require the use of at least one of the versions of the implementation specification adopted in § 170.215(k)(1) would enable health IT developers to use any version adopted at this location, unless we specify an “expiration” date 
                        <PRTPAGE P="63584"/>
                        which indicates a certain version of the specification may no longer be used after that date.
                    </P>
                    <FTNT>
                        <P>
                            <SU>191</SU>
                             
                            <E T="03">See https://hl7.org/fhir/us/carin-bb/.</E>
                        </P>
                    </FTNT>
                    <P>
                        We propose in § 170.315(g)(30)(iv)(B)(
                        <E T="03">1</E>
                        ) that the Health IT Module must support the “Authentication and Authorization Requirements” section of at least one of the versions of the implementation specification adopted in § 170.215(k)(1) (where we have proposed to adopt the CARIN IG for Blue Button® version 2.0.0—STU 2). These requirements establish authentication and privacy requirements to protect patient health information. We propose in § 170.315(g)(30)(iv)(B)(
                        <E T="03">2</E>
                        ) that the Health IT Module support the requirements described in the “C4BB CapabilityStatement” according to at least one of the versions of the implementation specification adopted in § 170.215(k)(1).
                    </P>
                    <P>We request comments on this proposal.</P>
                    <HD SOURCE="HD3">Support for CMS Requirements</HD>
                    <P>
                        The “patient access API” certification criterion proposed in § 170.315(g)(30), if finalized, would support the availability of certified health IT that can enable impacted payers 
                        <SU>192</SU>
                        <FTREF/>
                         to meet CMS requirements to implement and maintain a Patient Access API, as specified in 42 CFR 422.119, 431.60, 457.730, 438.242(b)(5), and 457.1233(d) and 45 CFR 156.221. Specifically, a Health IT Module certified to the proposed “patient access API” would facilitate access to data held by the payer, including: adjudicated claims (including cost); encounters with capitated providers; provider remittances; enrollee cost-sharing; all data classes and data elements included in a version of the USCDI standard at 45 CFR 170.213, formularies or preferred drug lists, and certain information about prior authorizations requests and decisions, as finalized in the CMS Interoperability and Patient Access Final Rule (85 FR 25542) and the CMS Interoperability and Prior Authorization Final Rule (89 FR 8784). We further note that we have proposed in section III.B.20.d. of this proposed rule to apply the API Conditions of Certification § 170.404(a), including transparency requirements in § 170.404(a)(2), and certain API Maintenance of Certification requirements in § 170.404(b), to the proposed “patient access API” and other criteria. These Conditions of Certification would, among other provisions, align with the API requirements finalized by CMS related to “Documentation requirements for APIs,” for instance, the requirement at 42 CFR 422.119(d) for MA organizations.
                    </P>
                    <FTNT>
                        <P>
                            <SU>192</SU>
                             As noted above, for the purposes of the CMS Interoperability and Patient Access and Interoperability and Prior Authorization Final Rules discussed in this section, impacted payers include Medicare Advantage (MA) organizations, state Medicaid fee-for-service (FFS) programs, state Children's Health Insurance Program (CHIP) FFS programs, Medicaid managed care plans, CHIP managed care entities, and Qualified Health Plan (QHP) issuers on the Federally-facilitated Exchanges (FFEs).
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">ii. Provider Access API—Client (§ 170.315(g)(31)) and Provider Access API—Server (§ 170.315(g)(32))</HD>
                    <P>We propose to adopt “provider access API—client” and “provider access API—server” certification criteria in § 170.315(g)(31) and § 170.315(g)(32), respectively. The proposed certification criteria would enable a health care provider to access information on patients' claims, including information about the patient's encounters, providers, organizations, locations, dates of service, diagnoses (conditions), procedures and observations. The proposed certification criteria could further enable access by a health care provider to clinical information maintained by the payer from sources other than claims, such as: laboratory results, clinical data from documents formatted in accordance with the Common Clinical Data Architecture (C-CDA), information from admit, discharge, and transfer (ADT) messages, information received from immunization registries, and information related to medications from pharmacy networks. Such information can provide a more complete clinical profile for the provider, as well as allow the provider to make appropriate treatment decisions based on both the clinical information and the patient's individual coverage information.</P>
                    <P>We propose that a Health IT Module certified to the “provider access API—client” in § 170.315(g)(31) support specified capabilities to enable a provider to request and receive patient clinical and coverage information from a payer and receive and process the response. We propose in § 170.315(g)(31)(i) that the Health IT Module must support the ability to request patient history according to at least one of the versions of the implementation specification adopted in § 170.215(k)(2) (where we have proposed to adopt the PDex IG version 2.0.0—STU2).</P>
                    <P>
                        Under § 170.315(g)(31)(ii), we propose that the Health IT Module must support specified API interactions as a client. First, in § 170.315(g)(31)(ii)(A) we propose that the Health IT Module support the capability to read and search the API. Specifically, in § 170.315(g)(31)(ii)(A)(
                        <E T="03">1</E>
                        ) we propose that the Health IT Module support the ability to interact with a “PDEX Server” as a client including support for all the corresponding client capabilities for requirements described in the “PDEX Server CapabilityStatement” and the HL7 FHIR Profiles, Resources, and operations included in Section 4.5.4 “CapabilityStatement,” according to at least one of the versions of the implementation specification adopted in § 170.215(k)(2) (where we have proposed to adopt the PDex IG version 2.0.0—STU2). In § 170.315(g)(31)(ii)(A)(
                        <E T="03">2</E>
                        ) we propose that the Health IT Module must support all the corresponding client capabilities for requirements included in the “C4BB CapabilityStatement” according to at least one of the versions of the implementation specification adopted in § 170.215(k)(1) (where we have proposed to adopt the CARIN IG for Blue Button® version 2.0.0—STU 2). In § 170.315(g)(31)(ii)(A)(
                        <E T="03">3</E>
                        ) we propose that the Health IT Module must support the corresponding client capabilities described in “US Core Server CapabilityStatement” according to an implementation specification adopted in § 170.215(b)(1) (where we have adopted US Core IG versions 3.1.1, which expires on January 1, 2026, US Core IG version 6.1.0, and proposed to adopt the US Core IG version 7.0.0) for each of the data classes and data elements included in at least one of the versions of the USCDI standard adopted in § 170.213 (where we have adopted USCDI version 1, which expires on January 1, 2026, USCDI version 3, which we propose will expire on January 1, 2028, and where we propose to adopt USCDI version 4).
                    </P>
                    <P>To support the transfer of information on groups of patients, we propose in § 170.315(g)(31)(ii)(B) that the Health IT Module must support the ability to request and receive information as a client according to at least one of the versions of the standard adopted in § 170.215(a) (where we have adopted FHIR® R4) and at least one of the versions of the implementation specification adopted in § 170.215(d) (where we have adopted the Bulk Data Access IG v1.0.0—STU 1, which we have proposed for expiration on January 1, 2028, and the Bulk Data Access IG v2.0.0—STU 2) for each of the data included in § 170.315(g)(31)(ii)(A), as described above.</P>
                    <P>
                        Additionally, we propose for the time period up to and including December 31, 2027, the Health IT Module must meet either the requirements specified in paragraph (g)(31)(ii)(B)(
                        <E T="03">1</E>
                        ) (proposed 
                        <PRTPAGE P="63585"/>
                        to be the “GroupLevelExport” operation) or both (
                        <E T="03">1</E>
                        ) and (
                        <E T="03">2</E>
                        ) (proposed to be the “_type” query parameter for each of the data included in 170.315(g)(31)(ii)(A)) of this section according to at least one of the versions of the implementation specification adopted in § 170.215(d). We propose that on and after January 1, 2028, the Health IT Module must meet the requirements specified in paragraph (g)(31)(ii)(B)(
                        <E T="03">1</E>
                        ) and (
                        <E T="03">2</E>
                        ) of this section according to at least one of the versions of the implementation specification adopted in § 170.215(d). For further discussion of these proposed requirements, which we have also proposed to include in other certification criteria that reference the Bulk Data Access IG, we refer readers to section III.B.14 of this proposed rule.
                    </P>
                    <P>We propose in § 170.315(g)(31)(iii) that the Health IT Module must support the ability to receive, parse, and write patient health history and coverage information to the Health IT Module for the following information. For clinical and coverage information, we propose in § 170.315(g)(31)(iii)(A) to include all FHIR Profiles and Resources included in the “PDEX Server CapabilityStatement” and the FHIR Profiles and Resources included in the Section 4.5.4 “FHIR CapabilityStatement” according to at least one of the versions of the implementation specification adopted in § 170.215(k)(2) (where we have proposed to adopt the PDex IG version 2.0.0—STU2). In § 170.315(g)(31)(iii)(B) we propose to include the information included in the “C4BB CapabilityStatement” according to at least one of the versions of the implementation specification adopted in § 170.215(k)(1) (where we have proposed to adopt CARIN IG for Blue Button® version 2.0.0—STU 2). Finally, in § 170.315(g)(31)(iii)(C) we propose to include the capabilities described in the “US Core Server CapabilityStatement” according to at least one of the versions of the implementation specification adopted in § 170.215(b)(1) (where we have adopted US Core IG version 3.1.1, which expires on January 1, 2026, US Core IG version 6.1.0, which we propose will expire on January 1, 2028, and where we propose to adopt US Core IG version 7.0.0) for each of the data classes and data elements included in at least one of the versions of the USCDI standard adopted in § 170.213 (where we have adopted USCDI version 1, which expires on January 1, 2026, USCDI version 3, which we propose will expire on January 1, 2028, and where we propose to adopt USCDI version 4).</P>
                    <P>We propose that a Health IT Module certified to the “provider access API—server” certification criterion in § 170.315(g)(32) would support capabilities to enable providers to request and receive patient health history and coverage information from payers. Similar to the “patient access API” certification criterion proposed in § 170.315(g)(30), we propose to require support for two registration pathways for Health IT Modules certified to the criterion. We propose in § 170.315(g)(32)(i)(A) that the Health IT Module must support functional registration for confidential apps according to the requirements included in § 170.315(j)(1). We propose in § 170.315(g)(32)(i)(B) that the Health IT Module must support dynamic registration according to the requirements in § 170.315(j)(2).</P>
                    <P>
                        We propose in § 170.315(g)(32)(ii) the authentication and authorization requirements for a Health IT Module certified to the “provider access API—server” criterion. We propose in § 170.315(g)(32)(ii)(A) that the Health IT Module must support the ability to authenticate and authorize an app during the process of granting access to patient data to users according to at least one of the versions of the implementation specification adopted in § 170.215(k)(2) (where we have proposed to adopt the PDex IG version 2.0.0—STU2) and at least one implementation specification adopted in § 170.215(c) (where we have adopted the SMART Application Launch Framework IG Release 1.0.0, which expires on January 1, 2026, the SMART App Launch IG Release 2.0.0, which we have proposed for expiration on January 1, 2028, and proposed to adopt the SMART App Launch IG Release 2.2.0). We propose in § 170.315(g)(32)(ii)(A)(
                        <E T="03">1</E>
                        ) that the Health IT Module must support asymmetric certificate-based authentication according to the requirements in § 170.315(j)(11) for user-facing apps dynamically registered using the capabilities in § 170.315(g)(32)(i)(B).
                    </P>
                    <P>
                        We propose authentication and authorization requirements for system access in § 170.315(g)(32)(ii)(B), including that the Health IT Module must support the ability to authenticate and authorize an app during the process of granting access to patient data to system apps according to at least one of the versions of the standard adopted in § 170.215(a) (where we have adopted FHIR R4) and at least one of the versions of the implementation specification adopted in § 170.215(d) (where we have adopted the Bulk Data Access IG v1.0.0—STU 1, which we have proposed for expiration on January 1, 2028, and proposed to adopt the Bulk Data Access IG v2.0.0—STU 2). We propose in § 170.315(g)(32)(ii)(B)(
                        <E T="03">1</E>
                        ) that the Health IT Module must support system authentication and authorization according to the requirements in § 170.315(j)(7) for system apps functionally registered using the capabilities in § 170.315(g)(32)(i)(A). We also propose in § 170.315(g)(32)(ii)(B)(
                        <E T="03">2</E>
                        ) the Health IT Module must support asymmetric certificate-based system authentication and authorization according to the requirements in § 170.315(j)(8) for system apps dynamically registered using the capabilities in § 170.315(g)(32)(i)(B).
                    </P>
                    <P>We propose in § 170.315(g)(32)(iii) that the Health IT Module must support specified capabilities to allow a provider to request patient health history and coverage information from a payer and to receive a response. Specifically, we propose in § 170.315(g)(32)(iii)(A) that the Health IT Module must support the ability for a client to request patient health history, coverage, and claims information according to at least one of the versions of the implementation specification adopted in § 170.215(k)(2) (where we have proposed to adopt the PDex IG version 2.0.0—STU2). We propose in § 170.315(g)(32)(iii)(B) that the Health IT Module support the ability to identify patient clinical, coverage, and claims information based on the information provided by the client in 170.315(g)(32)(iii)(A).</P>
                    <P>
                        We propose in § 170.315(g)(32)(iii)(C)(
                        <E T="03">1</E>
                        ) that the Health IT Module must support the requirements described in the “PDEX Server CapabilityStatement” and the HL7 FHIR Profiles and operations included in Section 4.5.4 “CapabilityStatement” via a standardized API according to at least one of the versions of the implementation specification adopted in § 170.215(k)(2). We propose in § 170.315(g)(32)(iii)(C)(
                        <E T="03">2</E>
                        ) that the Health IT Module support claims information by supporting the requirements included in the “C4BB CapabilityStatement” according to at least one of the versions of the implementation specification adopted in § 170.215(k)(1) (where we have proposed to adopt CARIN IG for Blue Button® version 2.0.0—STU 2). We propose in § 170.315(g)(32)(iii)(C)(
                        <E T="03">3</E>
                        ) that the API must support the capabilities described in “US Core Server CapabilityStatement” according to at least one of the versions of the implementation specification adopted in § 170.215(b)(1) (where we have 
                        <PRTPAGE P="63586"/>
                        adopted the US Core IG versions 3.1.1, which expires on January 1, 2026, the US Core IG version 6.1.0, and proposed to adopt the US Core IG version 7.0.0) for each of the data classes and data elements included in at least one of the versions of the USCDI standard adopted in § 170.213 (where we have adopted USCDI Version 1, which expires on January 1, 2026, USCDI version 3, which we propose will expire on January 1, 2028, and where we propose to adopt USCDI version 4).
                    </P>
                    <P>
                        We propose in § 170.315(g)(32)(iii)(D) that the Health IT Module must support returning patient clinical, coverage, and non-financial claims and encounter information according to at least one of the versions of the implementation specification in § 170.215(k)(2) (where we have proposed to adopt the PDex IG version 2.0.0—STU2) for each of the data included in § 170.315(g)(32)(iii)(C)(
                        <E T="03">1</E>
                        ), (
                        <E T="03">2</E>
                        ) and (
                        <E T="03">3</E>
                        ), as described above.
                    </P>
                    <P>
                        To support the transfer of information on groups of patients, we propose in § 170.315(g)(32)(iii)(E) that the Health IT Module must support responding to requests for patient data according to at least one of the versions of the standard adopted in § 170.215(a) (where we have adopted FHIR R4), and at least one of the versions of the implementation specification adopted in § 170.215 (d) (where we have adopted the Bulk Data Access IG v1.0.0—STU 1, which we have proposed for expiration on January 1, 2028, and the Bulk Data Access IG v2.0.0—STU 2) for each of the data included in § 170.315(g)(32)(C)(
                        <E T="03">1</E>
                        ), (
                        <E T="03">2</E>
                        ) and (
                        <E T="03">3</E>
                        ), as proposed above. For the time period up to and including December 31, 2027, we propose that the Health IT Module must meet either the requirements specified in (g)(32)(iii)(E)(
                        <E T="03">1</E>
                        ) (proposed to be the “GroupLevelExport” operation) or both (
                        <E T="03">1</E>
                        ) and (
                        <E T="03">2</E>
                        ) (proposed to be the “_type” query parameter for each of the data included in § 170.315(g)(32)(C), (D) and (E)), of this section according to at least one of the versions of the implementation specification adopted in § 170.215(d). On and after January 1, 2028, we propose the Health IT Module must meet the requirements specified in paragraph § 170.315(g)(32)(iii)(E)(
                        <E T="03">1</E>
                        ) and (
                        <E T="03">2</E>
                        ) of this section according to at least one of the versions of the implementation specification adopted in § 170.215(d).
                    </P>
                    <P>We request comments on this proposal.</P>
                    <HD SOURCE="HD3">Support for CMS Requirements</HD>
                    <P>
                        The “provider access API—server” certification criterion proposed in § 170.315(g)(32), if finalized, would support the availability of certified health IT that can enable impacted payers 
                        <SU>193</SU>
                        <FTREF/>
                         to meet CMS requirements to implement and maintain a Provider Access API as specified in 42 CFR 422.121(a), 431.61(a), 457.731(a), 438.242(b)(7), and 457.1233(d) and 45 CFR 156.222(a). Specifically, a Health IT Module certified to the proposed “provider access API—server” criterion would facilitate access to data held by the payer, including: claims and encounter data (excluding provider remittances and patient cost-sharing information), all data classes and data elements derived from a version of the USCDI standard adopted at 45 CFR 170.213, and certain information about prior authorizations requests and decisions, as required in the CMS Interoperability and Prior Authorization Final Rule (89 FR 8817).
                    </P>
                    <FTNT>
                        <P>
                            <SU>193</SU>
                             As noted above, for the purposes of the CMS Interoperability and Patient Access and Interoperability and Prior Authorization Final Rules discussed in this section, impacted payers include Medicare Advantage (MA) organizations, state Medicaid fee-for-service (FFS) programs, state Children's Health Insurance Program (CHIP) FFS programs, Medicaid managed care plans, CHIP managed care entities, and Qualified Health Plan (QHP) issuers on the Federally-facilitated Exchanges (FFEs).
                        </P>
                    </FTNT>
                    <P>In addition, the proposed “provider access API—client” certification criterion in § 170.315(g)(31) would establish the requirements for APIs to facilitate a provider request for this information, to ensure that providers can use certified health IT to access the information made available through a payer's Provider Access API.</P>
                    <HD SOURCE="HD3">iii. Payer-to-Payer API (§ 170.315(g)(33))</HD>
                    <P>We propose to adopt a “payer-to-payer API” certification criterion in § 170.315(g)(33) to specify requirements for Health IT Modules that can be used by payers to support electronic exchange between payer systems when patients transition between payers. Payer-to-payer data exchange that allows health data to follow the patient when they switch payers can enable improved coordination of care, increased patient empowerment, and reduced administrative burden.</P>
                    <P>Similar to the proposed “provider access API—client” and “provider access API—server” certification criteria, the proposed “payer-to-payer API” certification criterion would support the electronic request and sending of payer information related to both beneficiary coverage information and the clinical condition and care of the patient.</P>
                    <P>We propose two registration pathways for a Health IT Module certified to the proposed “payer-to-payer API” criterion. We propose in § 170.315(g)(33)(i)(A) that the Health IT Module must support registration for confidential apps according to the functional registration requirements in § 170.315(j)(1). We further propose in § 170.315(g)(33)(i)(B) that the Health IT Module must support dynamic registration according to requirements in § 170.315(j)(2).</P>
                    <P>We propose requirements for authentication and authorization in § 170.315(g)(33)(ii). In § 170.315(g)(33)(ii)(A) we propose that the Health IT Module must support system authentication and authorization according to the requirements in § 170.315(j)(7) for system apps functionally registered using the capabilities in § 170.315(g)(33)(i)(A). In § 170.315(g)(33)(ii)(B), we propose that the Health IT Module must support asymmetric certificate-based system authentication and authorization according to the requirements in § 170.315(j)(8) for system apps dynamically registered using the capabilities in § 170.315(g)(33)(i)(B).</P>
                    <P>We propose in § 170.315(g)(33)(iii)(A) that the Health IT Module must support the requirements included in the “Payer-to-Payer Exchange” section of at least one of the versions of the implementation specification adopted in § 170.215(k)(2) (where we have proposed to adopt the PDex IG version 2.0.0—STU2), as a client and server, including support for the following “Data Retrieval Methods” to allow access to information in § 170.315(g)(33)(iii)(B), (C), and (D): “Query all clinical resource individually,” “$patient-everything operation,” and “Bulk FHIR Asynchronous protocols.” We specifically request comment on the “Data Retrieval Methods” we should require as part of the “payer-to-payer API” certification criterion.</P>
                    <P>
                        To support the transfer of information on groups of patients, we propose in § 170.315(g)(33)(iii)(A)(
                        <E T="03">2</E>
                        ) that, for the time period up to and including December 31, 2027, the Health IT Module must respond to requests for patient data according to at least one of the versions of the standard adopted in § 170.215(a) (where we have adopted FHIR R4), and at least one of the versions of the implementation specification adopted in § 170.215(d) (where we have adopted the Bulk Data Access IG v1.0.0—STU 1, which we have proposed for expiration on January 1, 2028, and the Bulk Data Access IG v2.0.0—STU 2) for each of the data included in § 170.315(g)(33)(iii)(B), (C) and (D), as described below. Additionally, we propose for the time 
                        <PRTPAGE P="63587"/>
                        period up to and including December 31, 2027, the Health IT Module must meet either the requirements specified in paragraph (g)(33)(iii)(A)(
                        <E T="03">2</E>
                        )(
                        <E T="03">i</E>
                        ) (proposed to be the “GroupLevelExport” operation) or both (
                        <E T="03">i</E>
                        ) and (
                        <E T="03">ii</E>
                        ) (proposed to be the “_type” query parameter for each of the data classes and data elements included in at least one of the versions of the USCDI standard adopted in § 170.213) of this section according to at least one of the versions of the implementation specification adopted in § 170.215(d). We propose that on and after January 1, 2028, the Health IT Module must meet the requirements specified in paragraph (g)(33)(iii)(A)(
                        <E T="03">2</E>
                        )(
                        <E T="03">i</E>
                        ) and (
                        <E T="03">ii</E>
                        ) of this section according to at least one of the versions of the implementation specification adopted in § 170.215(d).
                    </P>
                    <P>We propose in § 170.315(g)(33)(iii)(B) that the Health IT Module must support the requirements described in the “PDEX Server CapabilityStatement” as a client and server via a standardized API according to at least one of the versions of the implementation specification adopted in § 170.215(k)(2) (where we have proposed to adopt the PDex IG version 2.0.0—STU2). We propose in § 170.315(g)(33)(iii)(C) that the Health IT Module must support sharing of claims information by supporting the data included in the “C4BB CapabilityStatement” according to at least one of the versions of the implementation specification adopted in § 170.215(k)(1) (where we have proposed to adopt CARIN IG for Blue Button® version 2.0.0—STU 2). We propose in § 170.315(g)(33)(iii)(D) that the Health IT Module must support the capabilities described in “US Core Server CapabilityStatement” according to the implementation specification in § 170.215(b)(1) (where we have adopted US Core IG version 3.1.1, which expires on January 1, 2026, US Core IG version 6.1.0, which we propose will expire on January 1, 2028, and where we propose to adopt US Core IG version 7.0.0) for each of the data classes and data elements included in at least one of the versions of the USCDI standard adopted in § 170.213 (where we have adopted USCDI version 1, which expires on January 1, 2026, USCDI version 3, which we propose will expire on January 1, 2028, and where we propose to adopt USCDI version 4).</P>
                    <P>We request comments on this proposal.</P>
                    <HD SOURCE="HD3">Support for CMS Requirements</HD>
                    <P>
                        The “payer-to-payer API” certification criterion proposed in § 170.315(g)(33), if finalized, would support the availability of certified health IT that can enable impacted payers 
                        <SU>194</SU>
                        <FTREF/>
                         to meet CMS requirements to implement and maintain a Provider Access API as specified in 42 CFR 422.119, 431.60, 457.730, 438.242(b)(5), and 457.1233(d) and 45 CFR 156.221. Specifically, a Health IT Module certified to the “payer-to-payer API” criterion would facilitate sharing between payers of claims and encounter data (excluding provider remittances and patient cost-sharing information), all data classes and data elements in at least one of the versions of the USCDI standard in § 170.213, and certain information about prior authorization requests and decisions, as required in the CMS Interoperability and Prior Authorization Final Rule (89 FR 8855).
                    </P>
                    <FTNT>
                        <P>
                            <SU>194</SU>
                             As noted above, for the purposes of the CMS Interoperability and Patient Access and Interoperability and Prior Authorization Final Rules discussed in this section, impacted payers include Medicare Advantage (MA) organizations, state Medicaid fee-for-service (FFS) programs, state Children's Health Insurance Program (CHIP) FFS programs, Medicaid managed care plans, CHIP managed care entities, and Qualified Health Plan (QHP) issuers on the Federally-facilitated Exchanges (FFEs).
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">iv. Prior Authorization API—Provider (§ 170.315(g)(34)) and Prior Authorization API—Payer (§ 170.315(g)(35))</HD>
                    <HD SOURCE="HD3">Background on Electronic Prior Authorization</HD>
                    <P>
                        Prior authorization processes 
                        <SU>195</SU>
                        <FTREF/>
                         have contributed significantly to patient and provider burden, for instance, through delays experienced by patients and clinicians as they seek to satisfy the requirements associated with prior authorization rules set by payers.
                        <SU>196</SU>
                        <FTREF/>
                         ONC's Strategy on Reducing Regulatory and Administrative Burden Relating to the Use of Health IT and EHRs,
                        <SU>197</SU>
                        <FTREF/>
                         released in 2020, identified challenges associated with the prior authorization process faced by patients and health care providers, including: (i) difficulty in determining whether an item or service requires prior authorization; (ii) difficulty in determining payer-specific prior authorization requirements for those items and services; (iii) inefficient use of provider and staff time to navigate communications channels such as fax, telephone, and various web portals; and (iv) unpredictable and lengthy amounts of time to receive payer decisions. The Strategy noted that payers and health IT developers have addressed prior authorization in an ad hoc manner with interfaces that reflect individual payer technology considerations, payer lines of business, and customer-specific constraints. A 2022 physician survey conducted by the American Medical Association demonstrated significant negative impacts associated with the current prior authorization and beneficiary information exchange processes.
                        <SU>198</SU>
                        <FTREF/>
                         Nearly 94 percent of physicians reported care delays associated with prior authorization, and 80 percent reported that issues related to the prior authorization process can sometimes lead to treatment abandonment. In addition, survey respondents reported that physicians and their staff spend almost two business days each week completing prior authorizations, with nearly 35 percent of physicians retaining staff who work exclusively on prior authorizations. Today, hospitals and provider practices widely continue to use telephone and fax to conduct prior authorization processes. According to the Council for Affordable Quality Healthcare, only 28 percent of 228 million prior authorization contacts were fully electronic in 2022.
                        <SU>199</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>195</SU>
                             Generally defined as rules imposed by healthcare payers that require approval for a medication, procedure, device, or other medical service be obtained prior to payment for the item or service.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>196</SU>
                             Office of the National Coordinator for Health Information Technology. Strategy on Reducing Regulatory and Administrative Burden Relating to the Use of Health IT and EHRs [PDF file]. February 2020. Retrieved from 
                            <E T="03">https://www.healthit.gov/sites/default/files/page/2020-02/BurdenReport_0.pdf.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>197</SU>
                             Office of the National Coordinator for Health Information Technology. Strategy on Reducing Regulatory and Administrative Burden Relating to the Use of Health IT and EHRs [PDF file]. February 2020. Retrieved from 
                            <E T="03">https://www.healthit.gov/sites/default/files/page/2020-02/BurdenReport_0.pdf.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>198</SU>
                             
                            <E T="03">https://www.ama-assn.org/practice-management/prior-authorization/prior-authorization-research-reports.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>199</SU>
                             
                            <E T="03">https://www.caqh.org/sites/default/files/2023-05/2022-caqh-index-report.pdf.</E>
                        </P>
                    </FTNT>
                    <P>
                        In 2020, ONC charged the HITAC to establish the Intersection of Clinical and Administrative Data (ICAD) Task Force to produce information and considerations related to the merging of clinical and administrative data for electronic prior authorization. The ICAD Task Force's final report,
                        <SU>200</SU>
                        <FTREF/>
                         approved in November 2020, recommended that ONC work with CMS, other Federal actors, and standards development organizations to “establish standards for prior authorization workflows.” Specifically, the Task Force recommended that entities should develop API specifications “such that the authorization and related documentation may be triggered in workflow in the relevant workflow 
                        <PRTPAGE P="63588"/>
                        system where the triggering event for the authorization is created.”
                    </P>
                    <FTNT>
                        <P>
                            <SU>200</SU>
                             
                            <E T="03">https://www.healthit.gov/sites/default/files/facas/ICAD_TF_FINAL_Report_HITAC_2020-11-06_508_0.pdf.</E>
                        </P>
                    </FTNT>
                    <P>In January 2021, ONC published an RFI titled “Request for Information: Electronic Prior Authorization Standards, Implementation Specifications, and Certification Criteria” to seek input from the public regarding electronic prior authorization standards, implementation specifications, and certification criteria that could be adopted within the ONC Health IT Certification Program (87 FR 3475). ONC received approximately 130 responses to this RFI from a wide range of entities. Comments on the RFI broadly supported the incorporation of electronic prior authorization capabilities within the Program, while highlighting concerns about the current readiness and maturity of available implementation specifications to support these capabilities. Commenters also provided input on how certification criteria related to electronic prior authorization should be structured and how certification criteria should address other Federal requirements around the use of standards for electronic prior authorization transactions. Finally, commenters provided input on the benefits of improving electronic prior authorization for patients, providers, health IT developers and payers, as well as potential challenges associated with implementation.</P>
                    <P>
                        ONC also charged the HITAC to establish a Task Force in order to provide input and recommendations in response to the RFI; the Task Force's recommendations were approved and submitted to ONC on March 10, 2022.
                        <SU>201</SU>
                        <FTREF/>
                         The proposals in this section would implement several recommendations from the Task Force, specifically recommendations to:
                    </P>
                    <FTNT>
                        <P>
                            <SU>201</SU>
                             
                            <E T="03">https://www.healthit.gov/sites/default/files/page/2022-03/2022-03-10_ePA_RFI_Recommendations_Report_Signed_508.pdf.</E>
                        </P>
                    </FTNT>
                    <P>• Create a suite of electronic prior authorization health IT certification criteria for health IT systems supporting both providers and payers that can enable health IT developers to certify to one or more specific functional capabilities that together, across participating health IT systems, enable the full electronic prior authorization workflow.</P>
                    <P>• Ensure new certification criteria for electronic prior authorization provide for health IT systems that perform prior authorization on behalf of payers to ensure that their solutions are compliant to consensus-based standards for electronic prior authorization and are able to send and receive information needed to meet the prior authorization business case.</P>
                    <P>
                        • Work with the Da Vinci Project and key healthcare stakeholders (
                        <E T="03">e.g.,</E>
                         providers, developers, patients) to develop appropriate health IT certification criteria that incorporate key functional capabilities for prior authorization.
                    </P>
                    <P>• Ensure certification requirements that allow a FHIR-enabled process for prior authorization transactions do not require translation to X12.</P>
                    <P>• Prioritize criteria based on the Da Vinci Prior Authorization Support (PAS) IG that allow data, C-CDA or FHIR documents to be provided in a FHIR construct.</P>
                    <HD SOURCE="HD3">Proposals</HD>
                    <P>We propose to adopt a “prior authorization API—provider” certification criterion in § 170.315(g)(34), which establishes requirements for Health IT Modules that can be used to facilitate a provider's request of coverage information and request for a prior authorization decision. We also propose to adopt a complementary “prior authorization API—payer” certification criterion in § 170.315(g)(35), which establishes requirements for Health IT Modules that can be used by a payer to accept prior authorization requests from a provider, send requested documentation and coverage information, and send prior authorization decisions. Together, these certification criteria would support real-time access for providers to payer approval requirements, documentation, and rules at point of service, as well as enable providers to request and receive authorization. We believe that technology certified to these capabilities would help to automate and streamline the prior authorization process for health care providers and payers, to ensure treatment decisions are made in a timely fashion, avoid delays in care, and reduce administrative burden on health care providers and payers associated with assembling and reviewing required documentation.</P>
                    <P>Both certification criteria are based on the HL7 FHIR Da Vinci Burden Reduction IGs, which we propose to adopt in § 170.215(j) and incorporate by reference in § 170.299:</P>
                    <P>
                        • HL7 FHIR Da Vinci—Coverage Requirements Discovery (CRD) Implementation Guide, Version 2.0.1—STU 2 (proposed in § 170.215(j)(1)(i)) 
                        <SU>202</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>202</SU>
                             
                            <E T="03">See https://hl7.org/fhir/us/davinci-crd/.</E>
                        </P>
                    </FTNT>
                    <P>
                        • HL7 FHIR Da Vinci—Documentation Templates and Rules (DTR) Implementation Guide, Version 2.0.1—STU 2 (proposed in § 170.215(j)(2)(i)) 
                        <SU>203</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>203</SU>
                             
                            <E T="03">See https://hl7.org/fhir/us/davinci-dtr/.</E>
                        </P>
                    </FTNT>
                    <P>
                        • HL7 FHIR Da Vinci—Prior Authorization Support (PAS) Implementation Guide, Version 2.0.1—STU 2 (proposed in § 170.215(j)(3)(i)) 
                        <SU>204</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>204</SU>
                             
                            <E T="03">See https://hl7.org/fhir/us/davinci-pas/.</E>
                        </P>
                    </FTNT>
                    <P>We propose to adopt these implementation specifications under PHSA section 3004 and make them available for HHS use. Taken together, these implementation specifications support a comprehensive workflow for conducting electronic prior authorization transactions. The proposed certification criteria below include proposals that require the use of at least one version for each of the implementation specifications adopted in § 170.215(j)(1)-(3). If we adopt subsequent versions of the implementation specifications in § 170.215(j)(1) (CRD IG), (j)(2) (DTR IG), and (j)(3) (PAS IG), respectively, proposals that require the use of at least one implementation specification adopted in one of these locations would enable health IT developers to use any version adopted at the specified location, unless we specify an adoption “expiration” date which indicates a certain version of the specification may no longer be used after that date.</P>
                    <P>First, we propose in § 170.315(g)(34)(i) and § 170.315(g)(35)(i) that the “prior authorization API—provider” and “prior authorization API—payer” certification criteria, respectively, must support capabilities related to coverage discovery. These proposals are intended to facilitate the automation of both information exchange and prior authorization and reduce the need for provider-end manual intervention. Health IT Modules certified to these certification criteria would be able to request coverage information from a payer, for instance when a future encounter is being scheduled for a patient, and to initiate prior authorization electronically when a treatment decision has been made. These requirements will ensure that providers can request and receive a wide variety of information including updates to coverage information, alternative services or products, documentation requirements and rules related to coverage, forms, and templates to complete, and indications of whether prior authorization is required.</P>
                    <P>
                        For the “prior authorization API—provider” certification criterion, in § 170.315(g)(34)(i), we propose that a Health IT Module certified to the 
                        <PRTPAGE P="63589"/>
                        criterion must support capabilities to initiate and exchange information with payer systems as a client to support the identification of coverage requirements. In § 170.315(g)(34)(i)(A) we propose that the Health IT Module must support the requirements described in the “Privacy, Security, and Safety” section of at least one of the versions of the implementation specification adopted in § 170.215(j)(1) (where we have proposed to adopt the CRD IG version 2.0.1—STU 2). In § 170.315(g)(34)(i)(B), we propose that the Health IT Module must support capabilities in § 170.315(j)(20) (where we have proposed to adopt the “workflow triggers for decision support interventions” certification criterion) to enable workflow triggers to call decision support services, including support for “appointment-book,” “encounter-start,” “encounter-discharge,” “order-dispatch,” “order-select,” and “order-sign” CDS Hooks according to at least one of the versions of the implementation specification adopted in § 170.215(j)(1) and requirements in § 170.315(j)(20).
                    </P>
                    <P>
                        In § 170.315(g)(34)(i)(C), we propose that the Health IT Module must support the requirements applicable to “CRD Clients” in at least one of the versions of the implementation specification in § 170.215(j)(1) including, as proposed in § 170.315(g)(34)(i)(C)(
                        <E T="03">1</E>
                        ), the requirements in the “CRD Client CapabilityStatement,” and, as proposed in § 170.315(g)(34)(i)(C)(
                        <E T="03">2</E>
                        ) support for the “SHOULD” requirements applicable to “CRD Clients” in Section 5.8 “Additional Data Retrieval.” We request public input on whether we should instead finalize a policy that these “SHOULD” requirements are treated as “SHALL” requirements.
                    </P>
                    <P>For the “prior authorization API—payer” certification criterion, we propose in § 170.315(g)(35)(i) that a Health IT Module certified to the criterion must support specified capabilities to exchange information with provider systems to support the identification of coverage requirements. We propose in § 170.315(g)(35)(i)(A) that the Health IT Module must support the ability to receive and respond to decision support requests as a service by supporting the capabilities in § 170.315(j)(21). In § 170.315(g)(35)(i)(B) we propose that the Health IT Module must support the requirements applicable to “CRD Server” included in at least one of the versions of the implementation specification adopted in § 170.215(j)(1) (where we have proposed to adopt the CRD IG version 2.0.1—STU 2) including the requirements in the “CRD Server CapabilityStatement.”</P>
                    <P>In § 170.315(g)(34)(ii) and § 170.315(g)(35)(ii)(B) we propose requirements for the “prior authorization API—provider” and “prior authorization API—payer” certification criteria, respectively, related to documentation and rules exchange. The DaVinci DTR and CRD IGs utilize Clinical Quality Language (CQL) to allow payers to inspect a patient's record for the necessary information related to the required documentation for a proposed item (such as durable medical equipment), medication, procedure, or other service. The DTR IG details the use of a payer provided Questionnaire resource and results from CQL execution to generate a QuestionnaireResponse resource containing the necessary information. This IG can allow payer APIs to specify how rules may be executed in a provider context so that documentation requirements are met, while at the same time reducing provider burden by reducing manual data entry.</P>
                    <P>For the “prior authorization API—provider” certification criterion, we propose in § 170.315(g)(34)(ii) that a Health IT Module certified to the criterion must support the ability to request and populate prior authorization documentation templates and rules from payer systems according to at least one of the versions of the implementation specification adopted in § 170.215(j)(2) (where we have proposed to adopt the DTR IG version 2.0.1—STU 2).</P>
                    <P>
                        “Light” DTR capabilities are applicable to EHRs that rely on a SMART on FHIR application to handle the form filling function of DTR. This requires the server to provide access to the specified resources to allow such an app to retrieve and edit QuestionnaireResponses and related resources. In § 170.315(g)(34)(ii)(A)(
                        <E T="03">1</E>
                        ), we propose the Health IT Module must support the capabilities included in the “Light DTR EHR” CapabilityStatement according to at least one versions of the implementation specification adopted in § 170.215(j)(2) (where we have proposed to adopt the DTR IG version 2.0.1—STU 2). In § 170.315(g)(34)(ii)(A)(
                        <E T="03">2</E>
                        )(
                        <E T="03">i</E>
                        ), we propose that the Health IT Module must support functional registration of the “DTR SMART Client” according to the requirements included in § 170.315(j)(1). We also propose in § 170.315(g)(34)(ii)(A)(
                        <E T="03">2</E>
                        )(
                        <E T="03">ii</E>
                        ) that the Health IT Module must support dynamic registration of the “DTR SMART Client” according to the requirements included in § 170.315(j)(2).
                    </P>
                    <P>
                        In § 170.315(g)(34)(ii)(A)(
                        <E T="03">3</E>
                        ), we propose that the Health IT Module must support launching the “DTR SMART Client” according to at least one of the versions of the implementation specification adopted in § 170.215(j)(2) (where we have proposed to adopt the DTR IG version 2.0.1—STU 2) to allow providers to launch an app to complete documentation for prior authorization according to at least one of the versions of the implementation specification in § 170.215(j)(2). In § 170.315(g)(34)(ii)(A)(
                        <E T="03">3</E>
                        )(
                        <E T="03">i</E>
                        ) we propose that the Health IT Module must support authentication and authorization during the process of granting access to patient data to users according to the requirements in § 170.315(j)(10). In § 170.315(g)(34)(ii)(A)(
                        <E T="03">3</E>
                        )(
                        <E T="03">ii</E>
                        ) we propose that the Health IT Module must support asymmetric certificate-based authentication according to the requirements in § 170.315(j)(11) for the “Light DTR Client” dynamically registered using the capabilities in § 170.315(g)(34)(ii)(A)(
                        <E T="03">2</E>
                        )(
                        <E T="03">ii</E>
                        ).
                    </P>
                    <P>In contrast to “Light DTR EHR” capabilities, “full” DTR capabilities are relevant to EHRs that manage the form filling functions of DTR internally. In § 170.315(g)(34)(ii)(B), we propose that the Health IT Module must support the capabilities included in the “Full DTR EHR” CapabilityStatement according to at least one of the versions of the implementation specification adopted in § 170.215(j)(2) (where we have proposed to adopt the DTR IG version 2.0.1—STU 2). Such EHRs need only support client capabilities for the Questionnaire Package, ValueSet Expand, and Next Question operations.</P>
                    <P>
                        For the “prior authorization API—payer” certification criterion, we propose in § 170.315(g)(35)(ii) that a Health IT Module certified to the criterion must support specified capabilities to exchange prior authorization documentation requirements with provider systems. In § 170.315(g)(35)(ii)(A)(
                        <E T="03">1</E>
                        ), we propose that the Health IT Module support functional registration for the “DTR SMART Client” and “Full DTR EHR” according to the requirements included in § 170.315(j)(1). In § 170.315(g)(35)(ii)(A)(
                        <E T="03">2</E>
                        ), we propose that the Health IT Module support dynamic registration for the “DTR SMART Client” and “Full DTR EHR” according to the requirements included in § 170.315(j)(2).
                    </P>
                    <P>
                        In § 170.315(g)(35)(ii)(B)(
                        <E T="03">1</E>
                        ) we propose that the Health IT Module support system authentication and authorization according to the requirements in § 170.315(j)(7) for the “DTR SMART Client” and “Full DTR 
                        <PRTPAGE P="63590"/>
                        EHR” functionally registered using the capabilities in § 170.315(g)(35)(ii)(A)(
                        <E T="03">1</E>
                        ). In § 170.315(g)(35)(ii)(B)(
                        <E T="03">2</E>
                        ) we propose that the Health IT Module support asymmetric certificate-based system authentication and authorization according to the requirements in § 170.315(j)(8) for the “DTR SMART Client” and “Full DTR EHR” dynamically registered using the capabilities in § 170.315(g)(35)(ii)(A)(
                        <E T="03">2</E>
                        ).
                    </P>
                    <P>
                        In § 170.315(g)(35)(ii)(C) we propose that the Health IT Module support the ability to receive and respond to a prior authorization documentation request with documentation templates and rules, according to at least one of the versions of the implementation specification adopted in § 170.215(j)(2) (where we have proposed to adopt the DTR IG version 2.0.1—STU 2), including in § 170.315(g)(35)(ii)(C)(
                        <E T="03">1</E>
                        ), the capabilities included in the “DTR Payer Service” CapabilityStatement, according to at least one of the versions of the implementation specification adopted in § 170.215(j)(2).
                    </P>
                    <P>Finally, in § 170.315(g)(34)(iii) and § 170.315(g)(35)(iii), we propose that the “prior authorization API—provider” and “prior authorization API—payer” certification criteria must support capabilities related to the submission, receipt, and response to a prior authorization request.</P>
                    <P>
                        For the “prior authorization API—provider” certification criterion, we propose in § 170.315(g)(34)(iii)(A) that the Health IT Module must support the ability to submit a prior authorization request to a payer system according to at least one of the versions of the implementation specification adopted in 170.215(j)(3) (where we have proposed to adopt the PAS IG version 2.0.1—STU 2). Specifically, we propose in § 170.315(g)(34)(iii)(A)(
                        <E T="03">1</E>
                        ) that the Health IT Module include support for the “EHR PAS Capabilities” CapabilityStatement according to at least one of the versions of the implementation specification adopted in § 170.215(j)(3).
                    </P>
                    <P>
                        We propose in § 170.315(g)(34)(iii)(A)(
                        <E T="03">2</E>
                        ) that the Health IT Module support the ability to include documentation created in § 170.315(g)(34)(ii) in a prior authorization request to a payer system according to at least one of the versions of the implementation specification adopted in § 170.215(j)(3). We propose in § 170.315(g)(34)(iii)(A)(
                        <E T="03">3</E>
                        ) that the Health IT Module support the ability to consume and process a “ClaimResponse” according to at least one of the versions of the implementation specification adopted in § 170.215(j)(3). Finally, we propose in § 170.315(g)(34)(iii)(A)(
                        <E T="03">4</E>
                        ) that the Health IT Module support subscriptions as a client according to the requirements in § 170.315(j)(24) and an implementation specification in § 170.215(j)(3), in order to support “pended authorization responses.”
                    </P>
                    <P>
                        For the “prior authorization API—payer” certification criterion, we propose in § 170.315(g)(35)(iii)(A)(
                        <E T="03">1</E>
                        ) that the Health IT Module must support functional registration according to the requirements included in § 170.315(j)(1), and propose in § 170.315(g)(35)(iii)(A)(
                        <E T="03">2</E>
                        ) to require support for dynamic registration according to the requirements included in § 170.315(j)(2). We propose in § 170.315(g)(35)(iii)(B)(
                        <E T="03">1</E>
                        ) that the Health IT Module must support system authentication and authorization according to the requirements in § 170.315(j)(7) for system apps functionally registered using the capabilities in § 170.315(g)(35)(iii)(A)(
                        <E T="03">1</E>
                        ). We propose in § 170.315(g)(35)(iii)(B)(
                        <E T="03">2</E>
                        ) that the Health IT Module must support asymmetric certificate-based system authentication and authorization according to the requirements in § 170.315(j)(8) for system apps dynamically registered using the capabilities in § 170.315(g)(35)(iii)(A)(
                        <E T="03">2</E>
                        ).
                    </P>
                    <P>
                        In § 170.315(g)(35)(iii)(C)(
                        <E T="03">1</E>
                        )-(
                        <E T="03">4</E>
                        ), we propose that the API must support the ability to receive, process, and respond to a prior authorization request according to at least one of the versions of the implementation specification adopted in § 170.215(j)(3) (where we have proposed to adopt the PAS IG version 2.0.1—STU 2). Specifically, we propose in § 170.315(g)(35)(iii)(C)(
                        <E T="03">1</E>
                        ) that the Health IT Module support “Intermediary PAS Capabilities.” We propose in § 170.315(g)(35)(iii)(C)(
                        <E T="03">2</E>
                        ) that the Health IT Module support an endpoint for receiving prior authorization requests. We propose in § 170.315(g)(35)(iii)(C)(
                        <E T="03">3</E>
                        ) that the Health IT Module support the ability to respond to a prior authorization request with a “ClaimResponse.” Finally, we propose in § 170.315(g)(35)(iii)(C)(
                        <E T="03">4</E>
                        ) that the Health IT Module must support subscriptions as a server according to the requirements in § 170.215(j)(3) to support “pended authorization responses” according to at least one of the versions of the implementation specification in § 170.215(j)(3).
                    </P>
                    <P>We request comments on this proposal.</P>
                    <HD SOURCE="HD3">Organization of the Proposed Prior Authorization API Criteria</HD>
                    <P>
                        In the January 2021 “Request for Information: Electronic Prior Authorization Standards, Implementation Specifications and Certification Criteria,” we requested comment on the most appropriate way to structure health IT certification criteria enabling a health care provider to conduct electronic prior authorization transactions (87 FR 3480). We received a wide range of input on this topic with commenters noting that different types of systems, including EHRs, revenue cycle and patient management systems, and third-party applications may be responsible for different elements of the electronic prior authorization workflow. Some commenters recommended that ONC consider proposing individual criteria that map to each of the Da Vinci IGs (the CRD, DTR, and PAS IGs) which we discussed in the RFI and have proposed to adopt in this proposed rule. Other commenters suggested creating more granular certification criteria which reflect specific capabilities and key interactions within the prior authorization workflow, so that these capabilities can be implemented as stand-alone solutions to provide incremental value. The Task Force charged by the HITAC to provide a response to the January 2021 RFI also provided recommendations on this topic.
                        <SU>205</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>205</SU>
                             
                            <E T="03">https://www.healthit.gov/sites/default/files/page/2022-03/2022-03-10_ePA_RFI_Recommendations_Report_Signed_508.pdf.</E>
                        </P>
                    </FTNT>
                    <P>
                        In this proposed rule, we have proposed a single prior authorization certification criterion for health care providers in § 170.315(g)(34). However, existing guidance in the Program could provide flexibility around the use of distinct technology products that may be utilized to perform the capabilities that are outlined in the proposed certification criterion. Specifically, health IT developers are permitted to use “relied upon software” (76 FR 1276) to demonstrate compliance with certification criteria adopted at 45 CFR part 170, subpart C.
                        <SU>206</SU>
                        <FTREF/>
                         Relied upon software is typically third-party software that is not developed by the health IT developer presenting its health IT for testing and certification. Relied upon software may be used to demonstrate compliance with a portion of an adopted certification criterion or an entire certification criterion. When a health IT developer relies upon software to demonstrate compliance with a certification criterion, such relied upon software must be included in the scope of the certification issued to the Health IT Module or Complete EHR. In cases where a Health IT Module may be 
                        <PRTPAGE P="63591"/>
                        paired with multiple “relied upon software” products for the same capability, it must be tested with at least one such product to demonstrate compliance with a certification criterion's requirements. Afterwards, the Health IT Module developer is permitted to list all additional “relied upon software” products for the same capability paired with the certified Health IT Module without having to test each one with the ONC-ATL. A health IT developer always remains responsible for its product's conformance to a certification criterion even when the “relied upon software” contributes to, or is the cause of, a non-conformity.
                    </P>
                    <FTNT>
                        <P>
                            <SU>206</SU>
                             For more guidance on relied upon software, 
                            <E T="03">see: https://www.healthit.gov/sites/default/files/relieduponsoftwareguidance.pdf.</E>
                        </P>
                    </FTNT>
                    <P>We invite additional comments on the most appropriate way to structure the proposed “prior authorization API—provider” certification criterion, as well as the “prior authorization API—payer” certification criterion. Specifically, we are interested in the public's input on how organization of the proposed certification criteria would affect the ability of developers to effectively offer certified health IT products that meet the criteria, and what impact the organization of the proposed criteria would have on customers who may already possess technology products that can be used to conduct electronic prior authorization transactions. We also request comment on whether or to what degree existing guidance for the Program, such as the relied upon software policy described above, would address scenarios in which distinct health IT products are used to support different elements of the prior authorization workflow. Finally, we invite comments on alternative approaches to organizing the “prior authorization API” certification criteria.</P>
                    <HD SOURCE="HD3">Support for CMS Requirements</HD>
                    <P>
                        The “prior authorization API—payer” certification criterion proposed in § 170.315(g)(35), if finalized, would support the availability of certified health IT that can enable impacted payers 
                        <SU>207</SU>
                        <FTREF/>
                         to meet CMS requirements to implement and maintain a Prior Authorization API as specified in 42 CFR 422.122(b), 431.80(b), 457.732(b), 438.242(b)(7), and 457.1233(d) and 45 CFR 156.223(b), respectively. Specifically, a Health IT Module certified to the “prior authorization API—payer” certification criterion would enable payers to make available information about documentation required for approval of any items or services that require prior authorization; support an automated process for prior authorization request and response; and communicate whether the payer approves the prior authorization request (and the date or circumstance under which the authorization ends), denies the prior authorization request (with a specific reason), or requests more information, as required in the CMS Interoperability and Prior Authorization Final Rule (89 FR 8897).
                    </P>
                    <FTNT>
                        <P>
                            <SU>207</SU>
                             As noted above, for the purposes of the CMS Interoperability and Patient Access and Interoperability and Prior Authorization Final Rules discussed in this section, impacted payers include Medicare Advantage (MA) organizations, state Medicaid fee-for-service (FFS) programs, state Children's Health Insurance Program (CHIP) FFS programs, Medicaid managed care plans, CHIP managed care entities, and Qualified Health Plan (QHP) issuers on the Federally-facilitated Exchanges (FFEs).
                        </P>
                    </FTNT>
                    <P>The “prior authorization API—provider” certification criterion proposed in § 170.315(g)(34), if finalized, would support the availability of certified health IT that can enable health care providers to interact with the APIs established pursuant to the payer API requirements referenced above, using certified health IT. CMS finalized Electronic Prior Authorization measures for the Medicare Promoting Interoperability Program and the MIPS Promoting Interoperability Performance Category in the CMS Interoperability and Prior Authorization Final Rule (89 FR 8909) which are intended to incentivize health care providers to interact with these APIs in order to submit prior authorization requests. If finalized, adopting and using technology certified to this criterion would enable eligible clinicians, and eligible hospitals and CAHs, to complete the prior authorization request actions associated with these measures using certified health IT.</P>
                    <HD SOURCE="HD3">Administrative Simplification Requirements Under HIPAA</HD>
                    <P>
                        We note that, pursuant to the administrative simplification rules established under HIPAA, the Secretary must adopt electronic standards for use by “covered entities,” which is defined as including health plans, healthcare clearinghouses, and certain health care providers.
                        <SU>208</SU>
                        <FTREF/>
                         The two standards adopted for referral certification and authorization transactions under the HIPAA administrative simplification rules (45 CFR 162.1302) include: NCPDP Version D.0 for retail pharmacy drugs; and X12 Version 5010x217 278 (X12 278) for dental, professional, and institutional request for review and response for items and services. HHS has also proposed to adopt the X12 275 standard, which is used to transmit additional documentation to support the exchange of the additional information that is required for prior authorization, in the “Administrative Simplification: Adoption of Standards for Health Care Attachments Transactions and Electronic Signatures, and Modification to Referral Certification and Authorization Transaction Standard” proposed rule (87 FR 78438).
                    </P>
                    <FTNT>
                        <P>
                            <SU>208</SU>
                             For more information, 
                            <E T="03">see https://www.cms.gov/priorities/key-initiatives/burden-reduction/administrative-simplification.</E>
                        </P>
                    </FTNT>
                    <P>Nothing in our proposed certification criteria related to electronic prior authorization would alter requirements for covered entities to use adopted HIPAA transaction standards. Moreover, the FHIR specifications we propose to adopt for these certification criteria would not conflict with the use of the adopted HIPAA standard, and we would expect covered entities using technology certified to these criteria to ensure compliance with applicable requirements.</P>
                    <P>
                        We note that in March 2021, the CMS National Standards Group (NSG), on behalf of HHS, approved an application 
                        <SU>209</SU>
                        <FTREF/>
                         from an industry group of payers, providers, and vendors for an exception under 45 CFR 162.940 from the HIPAA transaction standards for Da Vinci payers and their trading partners when using the FHIR standard for prior authorization. Under this exception, the group would test a prior authorization exchange using the HL7 FHIR Da Vinci standard without the X12 278 standard to determine whether this alternative standard for prior authorization could improve efficiency. HHS provides information about requests for exceptions from standards to permit testing of proposed modifications on the CMS HIPAA administrative simplification website.
                        <SU>210</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>209</SU>
                             
                            <E T="03">See https://confluence.hl7.org/display/DVP/Da+Vinci+HIPAA+Exception?preview=/113675673/113675685/Approval%20%232021031001.pdf.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>210</SU>
                             Centers for Medicare &amp; Medicaid Services (2022). Go-to-Guidance, Guidance Letters. Retrieved from 
                            <E T="03">https://www.cms.gov/priorities/key-initiatives/burden-reduction/administrative-simplification/subregulatory-guidance/letters.</E>
                        </P>
                    </FTNT>
                    <P>
                        On February 28, 2024, CMS NSG, on behalf of HHS, announced an application of enforcement discretion for HIPAA covered entities that implement FHIR-based Prior Authorization APIs as described in the CMS Interoperability and Prior Authorization Final Rule (89 FR 8758).
                        <SU>211</SU>
                        <FTREF/>
                         HHS stated that this action was in response to feedback received on multiple notices of proposed rulemaking and extensive stakeholder outreach and is intended to promote efficiency in the prior authorization 
                        <PRTPAGE P="63592"/>
                        process. Specifically, HHS stated that HIPAA Administrative Simplification enforcement action will not be taken against HIPAA covered entities that choose not to use the X12 278 standard as part of an electronic FHIR prior authorization process. HHS will continue to evaluate the HIPAA prior authorization transaction standards, including continuing to seek stakeholder input and evaluating the results of testing an all-FHIR-based transaction.
                    </P>
                    <FTNT>
                        <P>
                            <SU>211</SU>
                             
                            <E T="03">See https://www.cms.gov/files/document/discretion-x12-278-enforcement-guidance-letter-remediated-2024-02-28.pdf.</E>
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">v. Provider Directory API—Health Plan Coverage (§ 170.315(g)(36))</HD>
                    <P>We propose to adopt a “provider directory API—health plan coverage” certification criterion in § 170.315(g)(36) which would specify technical requirements for Health IT Modules that can enable publishing of information regarding the providers that participate in a payer's network. For beneficiary coverage and clinical information to be both useful to and utilized by patients and providers, it is necessary for patients to understand which providers, facilities, and pharmacies are covered by their current or future plan.</P>
                    <P>
                        The proposed certification criterion is based on the HL7 FHIR Da Vinci Payer Data Exchange Plan Net (PDex Plan Net) Implementation Guide version 1.1.0—STU1.1.
                        <SU>212</SU>
                        <FTREF/>
                         We propose, independent of the certification criterion proposal, to adopt this implementation specification in § 170.215(n)(1) and incorporate it by reference in § 170.299. We propose to adopt this implementation specification under PHSA section 3004 and make it available for HHS use. Use of this implementation specification can enable third parties to develop applications through which consumers and providers can query the participants in a payer's network that may provide services that address their healthcare needs. We propose in § 170.315(g)(36) that a Health IT Module certified to the criteria must support the ability to publish a payer's insurance plans, their associated networks, and the organizations and providers that participate in these networks according to at least one of the versions of the implementation specification adopted in § 170.215(n), including the requirements described in the “Plan-Net CapabilityStatement.” If we adopt subsequent versions of the PDex Plan Net IG in § 170.215(n), our proposal to require the use of at least one of the versions of the implementation specification adopted in § 170.215(n) would enable health IT developers to use any version adopted at this location, unless we specify an adoption “expiration” date, which indicates a certain version of the specification may no longer be used after that date.
                    </P>
                    <FTNT>
                        <P>
                            <SU>212</SU>
                             
                            <E T="03">See https://hl7.org/fhir/us/davinci-pdex-plan-net/STU1.1/.</E>
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Support for CMS Requirements</HD>
                    <P>
                        The “provider directory API—health plan coverage” certification criterion proposed in § 170.315(g)(36), if finalized, would support the availability of certified health IT that can enable impacted payers 
                        <SU>213</SU>
                        <FTREF/>
                         to meet CMS requirements to implement and maintain a Provider Directory API in 42 CFR 422.120, 431.70, 457.760, 438.242(b)(6), and 457.1233(d)(3), respectively. Specifically, a Health IT Module certified to the “provider directory API—health plan coverage” certification criterion would facilitate the availability of standardized information about a payer's provider networks, as well as pharmacy directory data, as required in the CMS Interoperability and Patient Access Final Rule (85 FR 25563).
                    </P>
                    <FTNT>
                        <P>
                            <SU>213</SU>
                             As noted above, for the purposes of the CMS Interoperability and Patient Access and Interoperability and Prior Authorization Final Rules discussed in this section, impacted payers include Medicare Advantage (MA) organizations, state Medicaid fee-for-service (FFS) programs, state Children's Health Insurance Program (CHIP) FFS programs, Medicaid managed care plans, CHIP managed care entities, and Qualified Health Plan (QHP) issuers on the Federally-facilitated Exchanges (FFEs).
                        </P>
                    </FTNT>
                    <P>We request comments on this proposal.</P>
                    <HD SOURCE="HD3">d. Revision and Addition of API Condition and Maintenance of Certification Requirements</HD>
                    <P>Given that we have proposed to adopt new certification criteria that would be applicable to certified API technology under the Program, we propose to extend the applicability of the API Conditions of Certification in § 170.404(a) and certain API Maintenance of Certification requirements in § 170.404(b) to Certified API Developers with Health IT Modules certified to the criteria proposed for adoption in § 170.315(g)(20), § 170.315(g)(30)-(36), and § 170.315(j). If our proposals are finalized, this would mean that the API Condition and Maintenance of Certification requirements would include within its scope the certification criteria adopted in § 170.315(g)(7)-(10), § 170.315(g)(20), § 170.315(g)(30)-(36), and § 170.315(j). We propose to make corresponding and conforming edits to § 170.404, including revisions to both § 170.404(a) and in § 170.404(b), to specify which API-related certification criteria apply in the context of each Condition and Maintenance of Certification requirement. We believe this approach is essential to continue to fulfill the statutory requirements set forth in PHSA § 3001(c)(5)(D)(iv), in particular Congress' requirement that a developer of certified health IT has “published application programming interfaces and allows health information from such technology to be accessed, exchanged, and used without special effort.” As we described in the ONC Cures Act Final Rule (84 FR 7476 through 7477), we established the API Condition and Maintenance of Certification requirements to, among other outcomes, promote transparency and pro-competitive business practices among Certified API Developers in pursuit of a policy that would result in access, exchange, and use of EHI “without special effort.” We believe that these same requirements should apply to developers of these new API-related certification criteria in § 170.315(g)(20) and (g)(30)-(36), and that the proposals to reference these certification criteria in § 170.404 would continue to adhere to our statutory charge to advance nationwide interoperability.</P>
                    <P>We propose in § 170.404(a)(2) to consolidate and establish documentation requirements that are currently required in § 170.315(g)(7)(ii), § 170.315(g)(9)(ii), and § 170.315(g)(10)(viii). Correspondingly, we propose to remove those three specified “documentation” paragraphs from those respective certification criteria because the consolidated conformance requirements would now be stated in the proposed § 170.404(a)(2). We believe that these documentation requirements should also pertain to the other API-related criteria we propose to adopt in § 170.315(g)(20), (g)(30)-(36), and § 170.315(j), and we believe that such requirements better fit as a generally applicable API Condition of Certification requirement than a functional requirement specified in each individual API-related certification criterion.</P>
                    <P>
                        Specifically, we propose in § 170.404(a)(2) that a Certified API Developer must publish complete business and technical documentation, including the documentation described in § 170.404(a)(2)(i)-(ii), via a publicly accessible hyperlink that allows any person to directly access the information without any preconditions or additional steps. In § 170.404(a)(2)(i), we propose that this should include technical documentation currently in § 170.315(g)(7), (9), and (10) such as API syntax, function names, required and optional parameters supported and their 
                        <PRTPAGE P="63593"/>
                        data types, return variables and their types/structures, exceptions and exception handling methods and their returns. We propose that § 170.315(g)(7)(ii) and § 170.315(g)(9)(ii) be reserved. Further, we propose in § 170.404(a)(2)(i)(B) that this technical documentation should include the software components and configurations that would be necessary for an application to implement in order to be able to successfully interact with the API and process its response(s); and in § 170.404(a)(2)(i)(C) that all applicable technical requirements and attributes necessary for an application to be registered with a Health IT Module's authorization server. We propose to revise § 170.404(a)(2)(ii) to require that API(s) must include complete accompanying business documentation that contains, at a minimum, the existing requirements currently in § 170.404(a)(2)(ii)(A) and (B).
                    </P>
                    <P>In addition to the proposed modifications to § 170.404(a), we propose to revise the Maintenance of Certification requirements for Application Programming Interfaces, in § 170.404(b). Specifically, we propose that the same authenticity verification and registration requirements currently in § 170.404(b)(1) apply to Certified API Developers with a Health IT Module certified to one or more of the certification criteria in of § 170.315(g)(10), (20), (30), (32)-(35). Similarly, we propose in § 170.404(b)(1)(i) that a Certified API Developer is permitted to institute a process to verify the authenticity of API Users so long as such process is objective and the same for all API Users and completed within ten business days of receipt of an API User's request to register their software application for use with the Certified API Developer's Health IT Module certified to any of the certification criteria in § 170.315(g)(10), (20), (30), (32)-(35). We propose that this process shall not apply to API Users that are part of a trust community supported at an API Information Source deployment submitting registration requests conformant to the specifications in § 170.215(o). In § 170.404(b)(1)(ii) we propose that a Certified API Developer must register and enable all applications for production use within five business days of completing its verification of an API User's authenticity, pursuant to paragraph (b)(1)(i) of this section. If the API User is part of a trust community supported at an API Information Source deployment and submitted a valid registration request conformant to the specifications in § 170.215(o), we propose that the application must instead be enabled for production use within one business day.</P>
                    <P>We propose in § 170.404(b)(2) to modify the existing publication and format requirements for service base URLs. We propose to refer to service base URLs as “API discovery details” and propose in § 170.404(b)(2)(i)(A) that these must be published publicly and at no charge for all customers regardless of whether the Health IT Module is centrally managed by the Certified API Developer or locally deployed by an API Information Source. We also propose in § 170.404(b)(2)(i)(B) that these API discovery details are reviewed quarterly and updated as necessary.</P>
                    <P>We also propose revisions to the formatting requirements of these API discovery details by adding to the current regulation text in § 170.404(b)(2)(i)-(iii) an option to publish API discovery details and related API Information source details, including the API Information Source's name, location, and facility identifier, according to the “User-access Brands and Endpoints” specification in at least one implementation specification adopted in § 170.215(c). We propose this at revised § 170.404(b)(2)(iii) and consolidate the regulation text currently in § 170.404(b)(2)(i)-(iii) as § 170.404(b)(2)(ii)(A)-(C). We propose that publication of API discovery details for patient access applies to Certified API Developers with Health IT Modules certified to either of the criteria in § 170.315(g)(10) and (g)(30) and we have established timelines for Health IT Modules certified to these criteria to conform to requirements in § 170.404(b).</P>
                    <P>Specifically, we propose that for the time period up to and including December 31, 2027, Certified API Developers with Health IT Modules certified to § 170.315(g)(10) must meet either the API discovery detail requirements in (i) and (ii) or the requirements in (i), (iii), and (iv) of this section. On and after January 1, 2028, all Certified API Developers with Health IT Modules certified to § 170.315(g)(10) must meet the requirements in (i), (iii), and (iv) of this section. Certified API Developers with Health IT Modules certified to § 170.315(g)(30) must meet the requirements in (i), (iii), and (iv) of this section. We believe this cadence and combination of requirements will support a gradual improvement in consistently available, standards-based access for patients seeking to access their health information via APIs.</P>
                    <P>
                        These Maintenance of Certification requirements are already established for Certified API Developers with a Health IT Module certified to the certification criterion adopted in § 170.315(g)(10), and we believe that extending these requirements to § 170.315(g)(30) is appropriate because this proposed certification criterion supports patient access to health and administrative (
                        <E T="03">e.g.,</E>
                         payer) information. Requirements in § 170.404(b)(1) and (2) facilitate the use of patient-facing applications and enable patient users to discover details necessary to connect to their data using an application of their choice.
                    </P>
                    <P>We request comment on these proposals.</P>
                    <P>In § 170.404(b)(3), we propose new Maintenance of Certification requirements for Certified API Developers with a Health IT Module certified to the certification criteria adopted in § 170.315(g)(32), § 170.315(g)(33), § 170.315(g)(35), or § 170.315(g)(36) to publish API discovery details. We propose in § 170.404(b)(3)(i) that the developer must publicly publish the API discovery details for all its customers, with Health IT Modules certified to § 170.315(g)(32), § 170.315(g)(33), § 170.315(g)(35) or § 170.315(g)(36) regardless of whether the Health IT Modules are centrally managed by the Certified API Developer or locally deployed by an implementer of the Certified API Developer.</P>
                    <P>We propose in § 170.404(b)(3)(ii) that the network information and related API Information Source details, including the API Information Source's name, location, and facility identifier, must be published in an aggregate vendor-consolidated Bundle according to the “User-Access Brands and Endpoints” specification in at least one implementation specification adopted in § 170.215(c). In § 170.404(b)(3)(iii) we propose that all API discovery details for payer information published according to this section must be reviewed quarterly and as necessary updated by the Certified API Developer.</P>
                    <P>While we recognize that this will require ongoing coordination between health IT developers and users of the Health IT Modules, as well as regular updates to the publicly available network information, we believe that making such information public is critical to establishing ongoing interoperability of administrative data. We welcome comment on these proposals.</P>
                    <P>
                        Finally, we propose revisions to two key terms in § 170.404(c). We propose to revise 
                        <E T="03">certified API technology</E>
                         to mean the capabilities of Health IT Modules that are certified to any of the API-focused certification criteria adopted in § 170.315(g)(7) through (10), (g)(20), (g)(30) through (36), and (j). This revision would support our proposed 
                        <PRTPAGE P="63594"/>
                        application of requirements in § 170.404 to the proposed APIs in § 170.315(g) and the proposed modular API capabilities in § 170.315(j). We also propose to revise 
                        <E T="03">Certified API Developer</E>
                         to mean a health IT developer that creates “certified API technology.” We believe this simplified definition for Certified API Developer will similarly support this term's application to the proposed API capabilities in § 170.315(g) and proposed modular API capabilities in § 170.315(j).
                    </P>
                    <P>We request comment on these proposals.</P>
                    <HD SOURCE="HD3">e. Revisions to Real World Testing Requirements</HD>
                    <P>
                        The Cures Act requires, as Condition and Maintenance of Certification requirements under the Program, that health IT developers successfully test the real world use of the technology for interoperability 
                        <SU>214</SU>
                        <FTREF/>
                         in the type of setting in which such technology would be marketed. As discussed in the ONC Cures Act Final Rule, the objective of real world testing is to verify the extent to which certified health IT deployed in production contexts continues to demonstrate conformance to the full scope of applicable certification criteria and functions with the intended use cases as part of the overall maintenance of a health IT's certification (85 FR 25766).
                    </P>
                    <FTNT>
                        <P>
                            <SU>214</SU>
                             Interoperability is defined in statute in section 3000 of the Public Health Service Act (as modified by section 4003 of the Cures Act) and defined in regulation at 45 CFR 170.102.
                        </P>
                    </FTNT>
                    <P>For reasons similar to our proposal to expand requirements in § 170.404 to the proposed certification criteria in § 170.315(g)(20), (g)(30) through (36), and 170.315(j), we propose to revise the real world testing requirements in § 170.405 by adding these proposed certification criteria in § 170.405(a). Given that each of these proposed new certification criteria is focused on interoperability and data exchange, we believe it is important that developers of certified health IT with Health IT Module(s) certified to these criteria participate in both Condition and Maintenance of Certification requirements. Per requirements in § 170.405(b) we also propose that developers of certified health IT with Health IT Modules certified to any one or more of the certification criteria in § 170.315(g)(20), (g)(30) through (36), and 170.315(j) also submit annual real world testing plans as well as annual real world testing results, which applies to any one or more of the criteria referenced in 170.405(a). We note that by including these criteria in § 170.405(a), that health IT developers may voluntarily avail themselves of SVAP flexibility so long as they ensure that their annual real world testing plans and real world testing results submissions address all the versions of all the standards and implementation specifications to which each Health IT Module is certified.</P>
                    <P>Given that we are proposing to reference several certification criteria in § 170.315(j) across various certification criteria in § 170.315(g), we clarify that a health IT developer with Health IT Module(s) certified to any one or more criteria in § 170.315(g) that successfully tests the real world use of those Health IT Module(s) will be considered conformant to the real world testing requirements for the corresponding certification criteria in § 170.315(j). We do not intend for Health IT Modules certified to any certification criterion in § 170.315(g) to submit duplicative real world testing plans or results for corresponding certification criterion in § 170.315(j) and believe this clarification will help reduce potential confusion for developers certified to criteria in § 170.315(g).</P>
                    <P>We request comments on this proposal.</P>
                    <HD SOURCE="HD3">f. Addition of Criteria to the Base EHR Definition</HD>
                    <P>Two of the certification criteria proposed in this section pertain to certified Health IT Modules intended for use by health care providers, specifically the “provider access API—client” and the “prior authorization API—provider” certification criteria in § 170.315(g)(31) and § 170.315(g)(34), respectively. We believe both certification criteria reflect fundamental capabilities, which would be appropriate for adoption by any health care provider using certified health IT. Technology certified to the “provider access API—client” criterion would enable a provider to receive key clinical and administrative information from a healthcare payer. Technology certified to the “prior authorization API—provider” criterion would enable a health care provider to conduct prior authorization requests and related interactions with payers that are widely used today.</P>
                    <P>We propose in § 170.102 in the definition of Base EHR to add the proposed certification criteria in § 170.315(g)(31) and § 170.315(g)(34) to the set of certification criteria adopted by the Secretary that are necessary to meet the Base EHR definition. We propose that the “provider access API—client” certification criterion in § 170.315(g)(31) would be necessary to meet the Base EHR definition on and after January 1, 2028. However, for the “prior authorization API—provider” certification criterion in § 170.315(g)(34), we propose that this criterion would be necessary to meet the Base EHR definition on and after January 1, 2027. This date is consistent with the policy finalized in CMS Interoperability and Prior Authorization Final Rule, which finalized an Electronic Prior Authorization measure in the Medicare Promoting Interoperability program and the MIPS Promoting Interoperability performance category which program participants must report on beginning with the CY 2027 EHR reporting period and CY 2027 performance period/2029 MIPS payment year, respectively (89 FR 8910).</P>
                    <P>We request comments on this proposal.</P>
                    <HD SOURCE="HD2">C. Conditions and Maintenance of Certification Requirements—Insights and Attestations</HD>
                    <HD SOURCE="HD3">1. Insights Condition and Maintenance of Certification Requirements</HD>
                    <HD SOURCE="HD3">a. Background</HD>
                    <P>The Cures Act specified requirements in section 4002(c) to establish an Electronic Health Record (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. In the HTI-1 Final Rule (89 FR 1311), we established the EHR Reporting Program as the “Insights Condition and Maintenance of Certification” (also referred to as the “Insights Condition”) and finalized in § 170.407 the first set of measures to reflect the interoperability category required by section 3009A(a)(3)(A)(iii) of the PHSA.</P>
                    <P>
                        We refer readers to the HTI-1 Proposed Rule (88 FR 23831) for detailed background on how we engaged with 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, and how our proposals to modify the measures that the Urban Institute developed is consistent with section 3009A(a)(4) of the PHSA. Our proposals with respect to each requirement continue to reflect how we propose to 
                        <PRTPAGE P="63595"/>
                        modify the set of measures in Urban Institute's final report.
                        <SU>215</SU>
                        <FTREF/>
                         As such, we propose modifications in this proposed rule as part of the next iteration of the Insights Condition and Maintenance of Certification requirements and welcome comments on our proposals below.
                    </P>
                    <FTNT>
                        <P>
                            <SU>215</SU>
                             
                            <E T="03">https://www.urban.org/research/publication/electronic-health-record-ehr-reporting-program-developer-reported-measures.</E>
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">b. Process for Reporting Updates</HD>
                    <P>In the HTI-1 Proposed Rule (88 FR 23847), we stated 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 also proposed in the HTI-1 Proposed Rule that in such scenarios, developers of certified health IT would need to renegotiate their contracts. We further explained that we expected developers of certified health IT would work to mitigate any issues and provisions affecting their ability to comply with the Insights Condition requirements.</P>
                    <P>In the HTI-1 Final Rule (89 FR 1347), we did not finalize our proposal to require developers of certified health IT to renegotiate contracts, when needed, with their customers to comply with the Insights Condition requirements. Instead, we finalized in § 170.407(a)(1)(i)(C) that health IT developers will need to provide ONC with information on the degree to which the data they submit are complete, specifically by reporting the percentage of their total customers as represented by hospitals for products used in inpatient settings and clinician users for products used in outpatient settings, that are included in their reported data for each metric for which they submit a response. We stated that the percentage of health care providers that are represented in the data provides transparency regarding the degree to which the data are complete.</P>
                    <P>
                        Detailed information regarding health care providers that are represented in the data would also help us further interpret the results of the data received and allow us to assess whether the data is nationally representative. This would also allow us to report results indicating whether, and how, the data are skewed. Therefore, we propose to add § 170.407(a)(1)(i)(D) to require developers of certified health IT to provide health care provider identifiers (
                        <E T="03">e.g.,</E>
                         National Provider Identifier (NPI), CMS Certification Number (CCN), or other type of unique national identifier) for providers included in the data submitted. Note, given this proposal, we propose to make conforming grammatical edits to the list structure in § 170.407(a)(1)(i)(B) and (C) to accommodate the proposed addition of (D). We also propose to revise § 170.407(a)(1)(i)(C) to remove the word “sites” from “hospital sites” to align with our proposal relating to the minimum reporting qualifications requirement described in detail further below.
                    </P>
                    <P>
                        The additional health care provider identifier information would help determine the representativeness of the data. Using the unique health care provider identifiers, we could link to other data sources such as the National Provider and Payer Enumeration System (NPPES) and CMS program participant data that would allow us to identify the types of providers included in the data. Knowing the different types of providers included in the data would allow us to determine if the data are skewed towards providers with certain characteristics associated with differences in health IT adoption and use, such as size, rural location and ownership.
                        <E T="51">216 217 218</E>
                        <FTREF/>
                         For example, based upon surveys of hospitals, larger hospitals tend to engage more in interoperability compared to smaller hospitals.
                        <SU>219</SU>
                        <FTREF/>
                         If the data disproportionately consist of larger hospitals, this could potentially skew the results towards higher performance on interoperability. To reduce burden, we intend to provide a template for developers of certified health IT to submit the data electronically, in a structured format, if our proposal is finalized.
                    </P>
                    <FTNT>
                        <P>
                            <SU>216</SU>
                             Strawley C., Everson J., Barker W. Hospital use of APIs to Enable Data Sharing Between EHRs and Apps. Office of the National Coordinator for Health Information Technology. Data Brief: 68. 2023. 
                            <E T="03">https://www.healthit.gov/data/data-briefs/hospital-use-apis-enable-data-sharing-between-ehrs-and-apps.</E>
                        </P>
                        <P>
                            <SU>217</SU>
                             Pylypchuk Y., J. Everson. (January 2023). Interoperability and Methods of Exchange among Hospitals in 2021. ONC Data Brief, no. 64. Office of the National Coordinator for Health Information Technology: Washington DC. 
                            <E T="03">https://www.healthit.gov/data/data-briefs/interoperability-and-methods-exchange-among-hospitals-2021.</E>
                        </P>
                        <P>
                            <SU>218</SU>
                             Pylypchuk Y., J. Everson, D. Charles, and V. Patel. (February 2022). Interoperability Among Office-Based Physicians in 2015, 2017, and 2019. ONC Data Brief, no.59. Office of the National Coordinator for Health Information Technology: Washington DC. 
                            <E T="03">https://www.healthit.gov/data/data-briefs/interoperability-among-office-based-physicians-2019.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>219</SU>
                             Pylypchuk Y., J. Everson. (January 2023). Interoperability and Methods of Exchange among Hospitals in 2021. ONC Data Brief, no. 64. Office of the National Coordinator for Health Information Technology: Washington DC. 
                            <E T="03">https://www.healthit.gov/data/data-briefs/interoperability-and-methods-exchange-among-hospitals-2021.</E>
                        </P>
                    </FTNT>
                    <P>We welcome comments on our proposal, and welcome comments on other alternatives that would offer a consistent approach for all health IT developers to report on the representativeness of the data provided to ONC. We continue to believe reporting the percentage of “clinicians” (for products primarily used in outpatient settings) and “hospitals” (for products primarily used in inpatient settings) in § 170.407(a)(1)(i)(C) is the best approach given that this aligns with CMS programs and is used to determine whether developers meet the threshold for reporting on the Insights Condition of Certification, however, we are open to considering alternatives that provide a consistent manner for developers to provide transparency on the degree to which the data are complete. This may also include removing the requirement for developers to provide the percentage of total customers that are represented in the data in § 170.407(a)(1)(i)(C), and instead only require developers to provide health care provider identifiers if that would provide a more consistent approach across developers and also allow us to gauge the representativeness of the data while reducing burden. We seek public feedback on approaches to understand the types and number of providers that are included in the data submitted, relative to the broader population of providers using the products of a developer of certified health IT. We also request comments for alternatives that may shift measurement from provider-based measures to patient-centered measures such as percentage and/or number of encounters or patients included in the data.</P>
                    <P>In the HTI-1 Final Rule (89 FR 1346), we finalized the Insights Condition reporting frequency to annually (once per year) 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 in § 170.407(b). We stated that developers of certified health IT who do not meet the minimum reporting qualifications would submit a response to specify that they do not meet the qualifications under the Insights Condition. 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 (89 FR 1345).</P>
                    <P>
                        We propose to revise § 170.407(b)(1) to make clear that all developers must provide responses to the Insights Condition of Certification on an annual basis regardless of how long a developer 
                        <PRTPAGE P="63596"/>
                        has or has had an active certification under the Program. Since all developers of certified health IT within the Program are required to submit a response, as finalized in HTI-1 Final Rule (89 FR 1345), we believe this revision will simplify and clarify expectations.
                    </P>
                    <P>We propose in § 170.407(b)(1)(ii) that the response a developer of certified health IT submits per the requirements of the Insights Condition, must be applicable to all their certified health IT as of January 1st of each year, beginning January 2026. For example, a developer of certified health IT who is submitting their response July 2027, would include data from all their applicable certified health IT from the prior year between January to December 2026 for their July 2027 submission. This has been the expectation from what we finalized in HTI-1 (89 FR 1348); however, we believe codifying the date of January 1st is necessary so that all health IT developers can determine whether they are required to report on a measure 18 months in advance of the response submission. This is similar to real world testing reporting requirements which has a specified date for all developers of certified health IT to assess their eligibility on submitting a real world testing plan per § 170.405. We strongly encourage developers of certified health IT to assess whether they meet the minimum reporting qualifications for the Insights Condition on January 1st of each year beginning in 2026. We intend to provide resources, outreach efforts, and other communications to aid developers of certified health IT in understanding the Insights Condition requirements. Our goal is to ensure there is adequate time allotted for reporting, clarity related to requirements, and an ability to address developers' questions and educational needs well in advance of any reporting deadlines. We welcome comments on our proposal and welcome alternative approaches that helps us achieve this goal.</P>
                    <P>
                        We include a table below as an example, and welcome comments on this approach and the proposed date, such as whether the date of January 1st should be earlier in the year (such as August 31st to align with Real World Testing eligibility date) 
                        <SU>220</SU>
                        <FTREF/>
                         to allow more time for developers to assess whether or not it meets the minimum reporting requirements for the upcoming data collection period.
                    </P>
                    <FTNT>
                        <P>
                            <SU>220</SU>
                             
                            <E T="03">See</E>
                             HTI-1 Final Rule Inherited Certified Status 89 FR 1198
                        </P>
                    </FTNT>
                    <GPH SPAN="3" DEEP="114">
                        <GID>EP05AU24.001</GID>
                    </GPH>
                    <P>We also propose in § 170.407(b)(2) that if developers update their certified health IT using Inherited Certified Status after January 1 of the year prior in which the responses are submitted, a health IT developer must include the newer version of the certified Health IT Module(s) in its annual responses to the Insights Condition of Certification. Many health IT developers update their certified Health IT Module(s) on a regular basis, leveraging the flexibility using Inherited Certified Status. This updating can cause an existing certified Health IT Module to be recognized as new within the Program due to the way ONC issues certification identifiers, and could result in existing certified Health IT Modules being inadvertently excluded from the Insights Condition requirements.</P>
                    <P>
                        In the HTI-1 Final Rule (89 FR 1344), we stated that we intend to make responses (the metrics and required documentation) to the Insights Condition made publicly available on ONC's website. We also stated that 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. We also indicated that 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, and if a health IT developer provided an affirmative indication, ONC would 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) (89 FR 1344 through 1345).
                    </P>
                    <P>To improve alignment and consistency with ONC's other certification requirements, we propose to revise § 170.407(a)(1)(i)(B) to specify that documentation must be available via a publicly accessibly hyperlink instead. We note that this applies to both required and optional documentation. This avoids health IT developers from sharing any potential proprietary, trade secret, and/or confidential information with ONC. We note that this process is consistent with other documentation reporting processes that are part of the Program.</P>
                    <HD SOURCE="HD3">c. Minimum Reporting Qualifications</HD>
                    <P>
                        In the HTI-1 Final Rule (89 FR 1345 through 1346), we finalized minimum reporting qualifications in a way that does not unduly disadvantage small and startup developers of certified health IT. We finalized in § 170.407(a)(2) that a developer of certified health IT must have at least 50 hospital sites or 500 individual clinician users across the developer's certified health IT to report on the measure. We noted 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). We propose to revise § 170.407(a)(2) by removing “sites” from hospital sites as the term could be misinterpreted.
                        <PRTPAGE P="63597"/>
                    </P>
                    <P>In addition, to ensure consistency in how health IT developers are interpreting and reporting on these terms, and to ensure there is no confusion regarding the types of hospitals and clinicians included, we clarify that the term “hospital” refers broadly to include various types of hospitals and is not limited to non-Federal acute care hospitals. This could include (but is not limited to) long term care hospitals, critical care hospitals, federally owned hospitals such as those operating under the U.S. Department of Veterans Affairs (VA), the U.S. Department of Defense (DOD), or the Indian Health Service (IHS), children's hospitals, psychiatric hospitals, etc. These hospitals could be identified with a CMS Certification number (CCN) or other unique identifier such as NPI or the American Hospital Association identifier.</P>
                    <P>We clarify the term “clinician users,” to include health care professionals consisting of a variety of backgrounds, including but not limited to: </P>
                    <FP SOURCE="FP-1">• Physicians (including Doctor of Medicine, osteopathy, dental surgery, dental medicine, podiatric medicine, and optometry)</FP>
                    <FP SOURCE="FP-1">• Osteopathic practitioners</FP>
                    <FP SOURCE="FP-1">• Chiropractors</FP>
                    <FP SOURCE="FP-1">• Physician assistants</FP>
                    <FP SOURCE="FP-1">• Nurse practitioners</FP>
                    <FP SOURCE="FP-1">• Clinical nurse specialists</FP>
                    <FP SOURCE="FP-1">• Certified registered nurse anesthetists</FP>
                    <FP SOURCE="FP-1">• Physical therapists</FP>
                    <FP SOURCE="FP-1">• Occupational therapists</FP>
                    <FP SOURCE="FP-1">• Clinical psychologists</FP>
                    <FP SOURCE="FP-1">• Qualified speech-language pathologists</FP>
                    <FP SOURCE="FP-1">• Qualified audiologists</FP>
                    <FP SOURCE="FP-1">• Registered dietitians or nutrition professionals</FP>
                    <FP SOURCE="FP-1">• Clinical social workers</FP>
                    <FP SOURCE="FP-1">• Certified nurse midwives</FP>
                    <P>
                        Although we seek to broadly define both “hospitals” and “clinicians” we realize that there may be benefits to aligning these terms with existing definitions as these are known and have been utilized over time. We are considering various options regarding whether to align the minimum reporting qualifications with definitions established for hospitals and clinicians by CMS, or in the Public Health Service Act (PHSA). For example, we are considering referring to the definition of “health care provider” as defined in section 3000(3) of the PHSA for “hospitals”, however, this definition may be too broad for the purposes of the Insights Condition. We are also considering the definition of “clinicians” as defined by CMS 
                        <SU>221</SU>
                        <FTREF/>
                         in their Merit-based Incentive Payment System (MIPS) program which would provide alignment and scope for provider types but may also be too restrictive since we require reporting from developers beyond those participating under CMS programs. Although the types of clinicians we provided as examples above are defined by CMS as “clinicians”, we do not wish to limit reporting for the Insights Condition to data that only relates to those participating in CMS programs given that many clinicians do not participate fully in these programs.
                        <SU>222</SU>
                        <FTREF/>
                         We seek comment on whether to keep our approach, or to align it with existing definitions to provide greater clarification and alignment with other requirements. Commenters are encouraged to specify alternatives that we should consider that would bring consistency and comparability across developers who will report under the Insights Condition. We are also considering and seek input from commenters on excluding clinicians who may only have an administrative role, which we would define as a clinician who does not treat patients. We note that this exclusion would not apply to a clinician conducting clinical research if the clinician directly treats patients.
                    </P>
                    <FTNT>
                        <P>
                            <SU>221</SU>
                             
                            <E T="03">https://qpp.cms.gov/mips/how-eligibility-is-determined.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>222</SU>
                             Apathy NC, Everson J. High Rates of Partial Participation in The First Year of The Merit-Based Incentive Payment System. Health Aff (Millwood). 2020 Sep;39(9):1513-1521. doi: 10.1377/hlthaff.2019.01648. PMID: 32897783; PMCID: PMC7720898.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">d. Measure Updates</HD>
                    <HD SOURCE="HD3">Individuals' Access to Electronic Health Information Through Certified Health IT Measure</HD>
                    <P>In the HTI-1 Final Rule (89 FR 1314), we finalized the “individuals' access to electronic health information through certified health IT” measure in § 170.407(a)(3)(i), which states that if a health IT developer has a Health IT Module certified to § 170.315(e)(1) or (g)(10) or both, the 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. We specified that the related metrics only count individuals' access to their EHI and stated in the HTI-1 Final Rule that we may incorporate patient-authorized representatives in future rulemaking (89 FR 1315). Therefore, we propose to revise § 170.407(a)(3)(i) to include both individuals and individuals' authorized representatives accessing their EHI (rather than just individuals alone).</P>
                    <P>
                        We believe it would be beneficial to align our measure with the Medicare Promoting Interoperability Program (PI) Measure for patient access (“Provide Patients Electronic Access to Their Health Information”),
                        <SU>223</SU>
                        <FTREF/>
                         which counts access by patients or their authorized representatives for measuring patient access using portals or apps. Therefore, we propose to expand the measuring of access to include access by individuals or their authorized representatives in § 170.407(a)(3)(i). We do not expect this additional measurement specificity will add substantive development effort for health IT developers as this proposal would align with how CMS operationalizes their measure for patient access.
                    </P>
                    <FTNT>
                        <P>
                            <SU>223</SU>
                             
                            <E T="03">https://qpp.cms.gov/docs/pi_specifications/Measure%20Specifications/2023MIPSPIMeasuresProvidePatientsElectronicAccess.pdf.</E>
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">C-CDA Reconciliation and Incorporation Through Certified Health IT Measure</HD>
                    <P>In the HTI-1 Final Rule (89 FR 1317), we finalized the “consolidated clinical document architecture (C-CDA) problems, medications, and allergies reconciliation and incorporation through certified health IT” measure in § 170.407(a)(3)(ii). The measure is intended to capture the use of C-CDAs in alignment with capabilities specified for the “clinical information reconciliation and incorporation” certification criterion in § 170.315(b)(2). Given the proposed updates to § 170.315(b)(2) discussed elsewhere in this proposed rule, we also propose conforming updates for this measure to ensure alignment with the certification criterion. We refer readers to section III.B.7 of this proposed rule for detailed discussion on the proposed revisions specific to § 170.315(b)(2). Therefore, we propose to revise the name of this measure to “C-CDA reconciliation and incorporation through certified health IT” in § 170.407(a)(3)(ii).</P>
                    <P>
                        In further alignment with the proposed revisions to the certification criteria in § 170.315(b)(2), we propose to require developers to submit responses on specific data classes and elements from C-CDA documents obtained and subsequently reconciled and incorporated both through manual and automated processes in § 170.407(a)(3)(ii)(E). Note, given this proposal, we propose to make conforming grammatical edits to the list structure in § 170.407(a)(3)(ii)(C) and (D) to accommodate the proposed addition of (E). If finalized as proposed in § 170.407(a)(3)(ii)(E), we would also provide technical updates resulting in 
                        <PRTPAGE P="63598"/>
                        additional metrics in the accompanying measure specification sheet which we discuss in further detail below under “technical updates.”
                    </P>
                    <P>
                        To provide adequate time for associated technical development and then reporting, we propose in § 170.407(b)(1)(i)(D) that any metrics in the accompanying measure specification sheet related to § 170.407(a)(3)(ii)(E) would be reported beginning July 2030, with data collection starting in 2029. We expect that several developers would likely provide information similar to the metrics described above in their 2023 Real World Testing Results, which would indicate the feasibility of generating these metrics.
                        <SU>224</SU>
                        <FTREF/>
                         We welcome comments on our proposals.
                    </P>
                    <FTNT>
                        <P>
                            <SU>224</SU>
                             
                            <E T="03">https://www.eclinicalworks.com/wp-content/uploads/2024/01/eCW-Real-World-Testing-2023-Results-Report-Jan-2024.pdf.</E>
                        </P>
                        <P>
                            <E T="03">https://www.epic.com/content/epiccare2023results.pdf.</E>
                        </P>
                        <P>
                            <E T="03">https://www.oracle.com/a/ocom/docs/industries/healthcare/2023-cerner-real-world-testing-results.pdf.</E>
                        </P>
                        <P>
                            <E T="03">https://www.azaleahealth.com/wp-content/uploads/2024/01/2023-RWT-Results-Report-Azalea-EHR.pdf.</E>
                        </P>
                        <P>
                            <E T="03">https://cantatahealth.com/wp-content/uploads/2024/01/Cantata-Health-Real-World-Testing-Results.pdf.</E>
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Technical Updates in Measure Specification Sheets</HD>
                    <P>
                        As proposed above, the proposed “individuals' access to electronic health information through certified health IT” measure consists of three metrics, as specified in the measure specification sheet, one of which is the number of unique individuals who accessed their EHI using technology certified to the “standardized API for patient population services” under § 170.315(g)(10). As we stated in the HTI-1 Final Rule (89 FR 1313), the measure specification sheets provide granular definitions and other information needed to operationalize the metrics to ensure they are implemented in a consistent manner across health IT developers. In the measure specification sheet, we defined measuring access to EHI for this measure by counting an individual's authorization, as indicated by an access token, at least once during the reporting period.
                        <SU>225</SU>
                        <FTREF/>
                         We intend to modify this definition in an updated version of the measure specification sheet as a technical update as it does not change the substance of this measure, since there may be instances where individuals authorize access to their data (via an access token) but no requests are made to retrieve the data. Given that our intent is to measure individuals' access to EHI (versus just authorizing access), we plan to update this definition in the measure specification sheet for this metric to further specify that access to EHI should be measured by counting the number of individuals where at least one FHIR resource was returned when using the “standardized API for patient population services” under § 170.315(g)(10) during the reporting period.
                    </P>
                    <FTNT>
                        <P>
                            <SU>225</SU>
                             
                            <E T="03">https://www.healthit.gov/sites/default/files/page/2023-12/Measure_Spec_Individual_Access_508.pdf.</E>
                        </P>
                    </FTNT>
                    <P>
                        We request comment on whether this definition should be updated in the measure specification in this manner, or alternatively, whether we should update it so that access to EHI is measured by counting the number of individuals where at least one FHIR request was made to access information using the “standardized API for patient population services” under § 170.315(g)(10) during the reporting period. We acknowledge that there may be concerns related to defining in terms of FHIR requests as we may technically be including unauthorized requests as a measure of access to EHI. We welcome comments and suggestions regarding modifying the original definition. As stated above, our website at the following link (
                        <E T="03">www.healthit.gov/proposedrule</E>
                        ) will have an accompanying measure specification sheet reflecting the technical specifications related to the substantive proposals in this proposed rule for commenters to view and consider. We refer readers to the HTI-1 Final Rule (89 FR 1312) where we explained that while the substantive requirements for each measure are defined through rulemaking, we determined that measure specification sheets are a logical and accessible method for the public to view the technical specifications that support those requirements.
                    </P>
                    <P>We stated in the HTI-1 Final Rule (89 FR 1322) 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. Therefore, we expect to update the metrics for the proposed “C-CDA reconciliation and incorporation through certified health IT” measure, within the accompanying measure specification sheet to align with the proposed broader set of data referenced by the criterion specified in § 170.315(b)(2) if finalized as proposed. As stated above, the accompanying measure specification sheet reflecting the technical updates to align with the proposed broader set of data in this proposed rule will be available on ONC's website for review to support public comment in a transparent manner. Specifically, we intend to replace references in the measure specification sheet for problems, medications, and allergies and intolerances with a reference to the proposed data specified in § 170.315(b)(2) and, consistent with the policy established in the HTI-1 Final Rule (see 89 FR 1312), we intend to continue to align measure specification sheets with any modifications to certification criteria finalized via notice and comment rulemaking—in this instance, specifically for § 170.315(b)(2). The specific data classes and elements proposed in § 170.407(a)(3)(ii)(E), that we intend to list in the measurement specification sheet as technical updates, are selected from the additional data that would be included in proposed § 170.315(b)(2) listed below:</P>
                    <P>• The data elements Substance (Medication) and Substance (Drug Class) in the Allergies and Intolerances data class.</P>
                    <P>• The data elements Patient Goals and SDOH Goals in the Goals data class.</P>
                    <P>• The data element Immunizations in the Immunizations data class.</P>
                    <P>• The data element Values/Results in the Laboratory data class</P>
                    <P>• The data element Medications in the Medications data class.</P>
                    <P>• The data element Unique Device Identifier—Implantable for a patient's implantable device(s) in the Medical Devices data class.</P>
                    <P>• The data element Assessment and Plan of Treatment in the Assessment and Plan of Treatment data class.</P>
                    <P>• The data element Problems and SDOH Problems/Health Concerns in the Problems data class.</P>
                    <P>We would provide technical updates resulting in additional metrics in the accompanying measure specification sheet that capture (1) the number of specific data elements obtained in the reporting period, and (2) the reconciliation of specific data, such as the number of problems reconciled and incorporated by various means. Together, this data would allow ONC to calculate how often problems and other data elements are reconciled and incorporated by various means using the number of each data element obtained and other existing metrics (such as the number of encounters) as denominators. We request comment on whether that approach would provide beneficial information commensurate with the potential burden for developers.</P>
                    <P>
                        Given the number of data elements that Health IT Modules certified to 
                        <PRTPAGE P="63599"/>
                        § 170.315(b)(2) would be able to reconcile and incorporate following the proposed revisions for the certification criteria, we have specified a limited set of Data Elements and Data Classes for which developers would count the number of Elements obtained and the number of Elements reconciled and incorporated for the Insights Condition in the measurement specification accompanying this proposed rule. We request comment on the specific Data Classes or Elements on which such metrics should focus. For instance, metrics specifically focused on reconciliation of medications may provide the most value in informing how often medication information is updated to accurately reflect care received from other organizations and allow for effective decision support; in contrast, metrics on reconciliation and incorporation of vital signs may provide relatively limited value.
                    </P>
                    <P>We also request comment on whether metrics should focus on specific data elements or should aggregate data elements to the data class level. For example, it may be more valuable and feasible to include a metric on the aggregate total number of substance (Medication) and substance (Drug Class) data elements within the Allergies and Intolerances data class rather than two separate metrics, one focused on Substance (Medication) and another focused-on Substance (Drug Class). We request comment on the feasibility and value of separate metrics by Data Element and aggregate elements by some or all Data Elements within a Data Class, which may differ by specific Element and Class.</P>
                    <P>We are also considering approaches to capture use of the proposed requirements for § 170.315(b)(2), if finalized as proposed, to support automatic reconciliation and incorporation in the accompanying measure specification sheet. As in prior versions of the measurement specification, the metric on the number of total C-CDAs obtained equals the sum of the metric on the number of total C-CDA documents obtained that were pre-processed and the metric on the number of total C-CDA documents obtained that were not pre-processed. We clarify that all documents for which reconciliation and incorporation is completed through fully automated processes would be considered to have been pre-processed for the purpose of this metric.</P>
                    <P>The measurement specification sheet further differentiates four metrics for pre-processed C-CDA documents: the first and second metrics respectively count pre-processed C-CDA documents that had data reconciled and incorporated via manual processes and fully automated processes, and the third and fourth metrics respectively count pre-processed C-CDA documents that were determined to have no data that modifies the patient record through manual processes and fully automated processes. These four metrics address pre-processed C-CDA documents that are manually acted upon or fully automated for reconciliation and incorporation but do not capture those C-CDAs that were obtained and pre-processed but not further acted upon by manual or fully automated processes.</P>
                    <P>The metric on the number of total C-CDA documents obtained that were not pre-processed is further differentiated by two metrics: the first metric counts C-CDA documents that were not pre-processed that had data reconciled and incorporated via manual processes, and the second metric counts C-CDA documents that were not pre-processed that were determined to have no data that modifies the patient record through manual processes. These two metrics account for all C-CDAs that are obtained, not pre-processed, and are then acted upon and do not include those C-CDAs that are obtained, not pre-processed, and not acted upon. While these sets increase the number of metrics to report, we believe they will clarify and simplify measuring and categorizing C-CDA documents.</P>
                    <P>In the HTI-1 Final Rule, we defined “Reconciled and Incorporated via Any Method” to be an 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 processes (89 FR 1319). Given the focus on automatic reconciliation and incorporation capabilities in this proposed rule for § 170.315(b)(2), we anticipate aligning the measure specification sheet by dividing the metrics that call for reporting on the total number of C-CDA documents that were reconciled and incorporated by “any method” into two categories: (1) C-CDA documents where data were reconciled and incorporated via manual processes performed by a clinician or their delegate only; and (2) a C-CDA documents where any data was reconciled and incorporated via fully automated processes. These additional metrics are intended to generate insight into the use of automatic capabilities and how often C-CDAs are reconciled and incorporated by fully automatic means.</P>
                    <P>
                        We have chosen these two categories to capture instances where the reconciliation and incorporation process is at least partly completed by automated means and because we believe that instances in which 
                        <E T="03">all</E>
                         data contained in a C-CDA are reconciled and incorporated via fully automated processes will be rare given the scope of data proposed to be included in the proposed § 170.315(b)(2). Alternatively, we could include an additional metric in the measure specification sheet to capture documents in which data is reconciled and incorporated through a mix of manual and automated processes, which would occur, for example, when problems were reconciled by automated processes and medications were reconciled by manual processes.
                    </P>
                    <P>We also intend to complement the existing metric focused on C-CDA documents that were determined to have no new information by pre-processes or fully automated processes with an additional metric. The additional metric would capture the number of C-CDA documents that were determined to have no new information by manual processes performed by a clinician or their delegate only. These two metrics focused on determining that there was no new information would therefore directly mirror the two metrics focused on reconciliation and incorporation following pre-processes. In revising these metrics, we are also considering alternatives that would describe the varied ways in which data contained within C-CDAs could lead to modification or reconciliation with the patients record. We request comment on whether metrics in the updated measure specification sheet that include the term 'no new data' clearly exclude instances where information in C-CDAs lead to a change to the patient's record. For example, if information in the patient record is deleted or modified in response to information in the C-CDA, the intention is that this be counted as an instance where information is reconciled and incorporated (either via manual or automated processes) and NOT as an instance where documents were determined to have no new data. If the current metrics are not clear, would it be more effective to revise the metrics on “no new data” as listed below:</P>
                    <P>• Number of total C-CDA documents obtained that were pre-processed and determined to have no data specified in § 170.315(b)(2) that modifies the patient record by manual processes performed by a clinician or their delegate.</P>
                    <P>
                        • Number of total C-CDA documents obtained that were pre-processed and 
                        <PRTPAGE P="63600"/>
                        determined to have no data specified in § 170.315(b)(2) that modifies the patient record by pre-processes or fully automated processes.
                    </P>
                    <P>• Number of total C-CDA documents obtained that were not pre-processed and determined to have no new data specified in § 170.315(b)(2) that modifies the patient record via manual processes performed by a clinician or their delegate only.</P>
                    <P>As noted earlier, please see the measure specification sheet that will be posted on ONC's website for review.</P>
                    <P>We request public comment on the definitions provided in that measure specification sheet for manual processes, and fully automated process as well as the feasibility of separately measuring those processes. We also request comment on whether the resulting separate metrics would effectively capture the use of the proposed new capabilities to automatically reconcile and incorporate information for § 170.315(b)(2), and request comment on the value of including a metric capturing when a “mix” of automated and manual processes were used to reconcile and incorporate data.</P>
                    <P>We also plan to make a technical update by revising the number of unique patients with an associated C-CDA document measure to instead capture the number of unique patients with an encounter and associated C-CDA document. The revised metric would be a direct subset of the existing metric Number of Unique Patients with an Encounter. The current metric comprehensively captures the number of patients with C-CDAs but may include some C-CDAs for patients who are not treated by a provider using the product during the reporting period. We do not anticipate any change in burden, and are requesting comment on the relative value of the altered metric.</P>
                    <P>In the HTI-1 Final Rule (89 FR 1326), we finalized the “use of FHIR in apps through certified health IT” in § 170.407(a)(3)(iv). This measure captures the volume and type of FHIR resources transferred to apps from certified health IT relative to the number of active certified API technology deployments. We intend to make a technical update in the accompanying measure specification sheet to provide additional implementation information specifying that reporting by user type should be done according to three mutually exclusive categories: patient-facing only, non-patient facing only, and both patient-facing and non-patient facing.</P>
                    <P>In the HTI-1 Final Rule (89 FR 1332), we finalized the “immunization administrations electronically submitted to immunization information systems through certified health IT” measure in § 170.407(a)(3)(vi). We stated that this measure would report on the volume of immunization administrations electronically submitted to an immunization information system through certified health IT. In the accompanying measure specification sheet, we indicated that the number of immunizations administered that were electronically submitted successfully to IISs overall was defined as the total number of messages submitted to IISs, minus acknowledgements with the error of severity level E. We intend to make a few technical updates to this measure specification sheet. First, we intend to add metrics to separately count the number of immunizations administered electronically submitted to IISs that returned with an acknowledgement with the error of severity level E during the reporting period overall, and by IIS and age category. These additional metrics would enable us to identify potential issues associated with submissions to the IIS. We do not expect any additional burden associated with reporting this metric. We also request comment on the value and burden associated if we have the metrics count the immunizations administered electronically returned by their acknowledgement code (by IIS and age) instead, which would allow us to understand the number of messages that were rejected, had errors, and were accepted by IIS and age.</P>
                    <P>We also intend to make another technical update to the measure specification sheet by adding metrics to separately count the number of immunizations administered that were electronically submitted to IIS where an acknowledgement from an IIS is not received by certified health IT overall, and by IIS and age category. The current measure specification sheet indicates health IT developers optionally report on number of submissions that did not receive acknowledgement as part of the supplemental documentation. These separate metrics would enable monitoring the occurrence of these communication failures between certified health IT and IIS more systematically. We do not expect substantive additional burden associated with this metric. We also request comment on the value and burden associated with reporting a count of the subset of messages sent to third party intermediaries where the third-party intermediary does not provide an acknowledgement that the message was sent to an IIS. Finally, we intend to make a technical update that would clarify that the immunization administration submitted would include HL7 Z22 messages, and request comment on this approach. This aligns with the “immunization history and forecasts through certified health IT” measure specification sheet where we indicate that “the successful response received from IIS” include HL7 Z42 and Z32 messages.</P>
                    <P>
                        In the HTI-1 Final Rule (89 FR 1336), we finalized the “immunization history and forecasts through certified health IT” measure in § 170.407(a)(3)(vii). This measure captures the use of certified health IT to query information from an IIS under the “transmission to immunization registries” (§ 170.315(f)(1)) criterion. In the accompanying measure specification sheet, we indicated that the number of immunization queries sent to IISs overall metric would be defined as the total number of messages sent to IISs, minus acknowledgements with errors (severity level E). We intend to make a technical update and modify this definition in the measure specification sheet as it does not change the substance of this measure. We plan to update this definition so that the number of immunization queries sent to IISs overall metric should be measured by only counting the total number of immunization queries sent to IISs during the reporting period. This metric no longer requires subtracting the number of acknowledgements with the error of severity level E. Instead, we are adding separate metrics in the measure specification sheet which would report on the total number of queries responses that returned with acknowledgements that had an error of severity level E, overall and by IIS, during the reporting period. This would enable us to understand how many queries were rejected by an IIS (as indicated by an “E” code) during the reporting period. We do not expect any additional burden associated with metric. We also plan to make a technical update to the definition of “queries sent” to IISs such that the definition of queries sent applies to HL7 Z34 and HL7 Z44 messages. This approach would provide consistency in how queries sent are defined across developers. Additionally, it would align the definition of “queries sent” with “successful response received from IIS,” which is based upon the receipt of HL7 Z42 and Z32 messages. We also request comment on the value and burden associated if we have the metrics count the query responses returned by their acknowledgement code (by IIS) instead, 
                        <PRTPAGE P="63601"/>
                        which would allow us to understand the number of queries sent where data was found, no data was found, or multiple candidates exist, or where query messages that were rejected, had errors, and were accepted by IIS.
                    </P>
                    <P>In the HTI-1 Final Rule (89 FR 1338) we also received a couple comments noting that a significant portion of messaging failures are communication failures where there will be no response received. A commenter suggested that messages with no response from the IIS (in the case of downtime, for example) would be considered successful (89 FR 1338). In response, we stated that at this time, we will not require health IT developers to provide separate counts for communication failures and counts of the descriptive context levels, and encouraged developers capture information about communication failures as their functionality permits and include this explanation in the supplemental documentation. We also stated that we would collaborate with the community to monitor how these instances impact the measure's interpretation and determine if it should be revised in the future.</P>
                    <P>Given the potential value of understanding the frequency of these communication failures, we plan to make a technical update in the accompanying measure specification sheet to create additional metrics which would report on the total number of queries sent but where no acknowledgement was received from the IIS overall, and by IIS. The separate metric to count no acknowledgements would allow us and the CDC to monitor the occurrence of these communication failures between certified health IT and IIS rather than relying on supplemental reporting to gather this information. We do not expect substantive additional burden associated with this metric. We also request comment on the value and burden associated with reporting a count of the queries sent to third party intermediaries where the third-party intermediary does not provide an acknowledgement the query was sent onto an IIS.</P>
                    <HD SOURCE="HD3">2. Attestations Condition and Maintenance of Certification Requirements</HD>
                    <P>The Cures Act amended section 3001(c)(5) of the PHSA by adding the requirements that a health IT developer, as a Condition and Maintenance of Certification requirement under the Program, provide assurances to the Secretary, unless for legitimate purposes specified by the Secretary, that it will not take any action that constitutes information blocking as defined in section 3022(a) of the PHSA, or any other action that may inhibit the appropriate exchange, access, and use of EHI. In the ONC Cures Act Final Rule, we established both Assurances (§ 170.402) and Attestations (§ 170.406) Conditions and Maintenance of Certification requirements (88 FR 75718 and 88 FR 25781, respectively).</P>
                    <P>In the HTI-1 Proposed Rule (88 FR 23782) and Final Rule (89 FR 1237), we proposed and finalized the adoption of the certification criterion, “decision support interventions” in § 170.315(b)(11) as part of the “care coordination certification criteria,” in § 170.315(b). In the HTI-1 Final Rule, we narrowed the overall scope of technologies impacted by finalized requirements in § 170.315(b)(11) (89 FR 1251 through 1252). We 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 its customers. Specifically, we finalized a configuration nexus for several requirements in § 170.315(b)(11) that centered on whether the developer of certified health IT supplied a Predictive DSI as part of its Health IT Module.</P>
                    <P>We also finalized in the HTI-1 Final Rule a supportive Maintenance of Certification requirement as part of the Assurances Condition of Certification in § 170.402(b) for § 170.315(b)(11). We finalized in § 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) (89 FR 1253 through 1254). These policies establish ongoing requirements for developers of certified health IT with Health IT Modules certified to § 170.315(b)(11) to address circumstances where a developer chooses to supply a Predictive DSI as part of its Health IT Module after its initial certification to § 170.315(b)(11), as well as circumstances where a developer that formerly supplied a Predictive DSI as part of its Health IT Module when initially certifying to § 170.315(b)(11) no longer chooses to do so.</P>
                    <P>We propose to add a conforming update to the Attestation Condition of Certification by revising § 170.406(a)(2) to address the Assurance Maintenance of Certification requirement in § 170.402(b)(4). We note that as a function of providing attestations twice yearly, developers of certified health IT with Health IT Modules certified to § 170.315(b)(11) would be expected to affirm conformance to the Assurances Maintenance of Certification requirement in § 170.402(b)(4); specifically, they would attest that they have reviewed and updated, as necessary, the required attribute information and documentation during the time covered by the attestation. We welcome comment on this proposal.</P>
                    <HD SOURCE="HD2">D. Administrative Updates</HD>
                    <HD SOURCE="HD3">1. Program Correspondence</HD>
                    <P>We propose to revise the Program correspondence provision (§ 170.505(a)(2)) to clarify that under Program regulations, the applicant for ONC-Authorized Testing Lab (ONC-ATL) status, the applicant for an ONC-Authorized Certification Body (ONC-ACB), an ONC-ONC-ACB, an ONC-ATL, health IT developer or any party to proceeding under subpart E of part 170 will be considered to have received correspondence or other written communications from ONC or the National Coordinator when the first of the following three scenarios occurs: (1) the date on which ONC or the National Coordinator receives a response to the correspondence via written or verbal communication methods; (2) the date of the delivery confirmation to the address on record for correspondence sent by express or certified mail; or (3) the date of the seventh business day after the date on which the email, express, or certified mail was sent.</P>
                    <P>
                        ONC explained in the ONC Cures Act Proposed Rule preamble that “we consider a `business day' to include the normal workdays and hours of operation during a week (Monday through Friday), excluding Federal holidays and weekends.” 
                        <SU>226</SU>
                        <FTREF/>
                         We propose to codify in 45 CFR 170.102 a definition of “business days” that would include the same days as our explanation in the ONC Cures Act Proposed Rule. ONC's definition of business days for purposes of 45 CFR part 170 would also include those days on which the Office of Personnel Management has announced that Federal agencies in the Washington, DC area are closed, reflecting the nationwide scope of the Program. The “business days” definition proposed in § 170.102 would provide clarity about 
                        <PRTPAGE P="63602"/>
                        which days would be counted when determining the date of the seventh business day after the date on which the email, regular, express, or certified mail was sent, as proposed in § 170.505(a)(2)(iii).
                    </P>
                    <FTNT>
                        <P>
                            <SU>226</SU>
                             
                            <E T="03">https://www.federalregister.gov/d/2019-02224/p-889.</E>
                        </P>
                    </FTNT>
                    <P>
                        In the ONC Cures Act Proposed Rule at 84 FR 7503, referencing a statement the Enhanced Oversight and Accountability Final Rule (EOA Final Rule) (81 FR 72404), we signaled our intent to send notices of potential non-conformity, non-conformity, suspension, proposed termination, and termination 
                        <E T="03">via certified mail</E>
                         (81 FR 72429). We solicited comments on the ONC Cures Act Proposed Rule regarding the nature and types of non-conformities with the Conditions and Maintenance of Certification requirements that ONC should consider in determining the method of correspondence. Specifically, we asked whether certain types of notices under direct review should be considered more critical than others and, thus, might require a specific method of correspondence (84 FR 7504). In the ONC Cures Act Final Rule, we finalized the proposal to use the provisions in § 170.505 for correspondence regarding compliance with the Conditions and Maintenance of Certification requirements with minor revisions outlining specific considerations for when we would provide notice beyond email (85 FR 25784).
                    </P>
                    <P>When we finalized our proposal in the ONC Cures Act Final Rule, we did not anticipate the several challenges we encountered with certain correspondence beyond email during the COVID-19 pandemic. As the volume of correspondence and communication required to fulfill ONC review and enforcement responsibilities for the Conditions and Maintenance of Certification requirements (subpart D of 45 CFR part 170) has increased, we have experienced difficulties with delivery of paper-based correspondence that we did not experience with email.</P>
                    <P>To avoid undue delays in addressing non-conformities with Program requirements or resolving other matters, we propose in § 170.505(a)(2)(iii) that seven business days after a written communication is sent is the latest of three dates on which we would consider the communication to have been received by the recipient. In § 170.505(a)(2)(i), where we receive a communication from the ONC-ACB, ONC-ATL, applicant, developer, or other party in response to a written correspondence, we believe that response is sufficient to demonstrate the communication has been received. Similarly, in § 170.505(a)(2)(ii) a delivery confirmation date, such as from the United States Postal Service (USPS) for certified mail, that is fewer than seven business days after the communication was sent would be considered the day the communication was received.</P>
                    <P>We welcome comments on this proposal and whether we should consider moving away from using non-electronic means of communication for anything except courtesy copies of communications.</P>
                    <HD SOURCE="HD3">2. ONC-Authorized Certification Bodies (ACB) Surveillance of Certain Maintenance of Certification Requirements</HD>
                    <HD SOURCE="HD3">a. Background and Proposal Summary</HD>
                    <P>To better support health IT developers' ability to consistently meet their obligations under subpart D of 45 CFR part 170, we propose to adopt new requirements in § 170.523 principles of proper conduct (PoPCs) for ONC-ACBs and new procedures for in-the-field surveillance of the maintenance of certification for Health IT in § 170.556 that would build on ONC-ACBs' existing surveillance responsibilities and obligations. More specifically, we propose to adopt new surveillance reporting requirements in § 170.523(i), reporting for corrective action plan (CAP) non-compliance in § 170.523(x), new oversight responsibilities of certain Maintenance of Certification requirements in § 170.523(p) and (q), new and revised surveillance requirements in § 170.556(b), and new and revised procedures for CAPs in § 170.556(d).</P>
                    <P>We believe these proposed new and revised surveillance and PoPC requirements would promote Program efficiency and encourage Program-participating developers to maintain, or when necessary, regain, conformity with Program requirements for the applicable Maintenance of Certification requirements as required by the Program regulations promulgated under the Cures Act. Section 4002(a) of the Cures Act amended section 3001(c)(5) of the PHSA by adding paragraph (c)(5)(D), which requires the Secretary, through notice and comment rulemaking, to require certain conditions of certification and maintenance of certification for the Program. In the ONC Cures Act Final Rule, we established Conditions and Maintenance of Certification requirements pursuant to PHSA 3001(c)(5)(D)(i) through (vi) in subpart D of 45 CFR part 170 (85 FR 25783). In the HTI-1 Final Rule, we established the Insights Condition and Maintenance of Certification requirements (§ 170.407) pursuant to PHSA 3001(c)(5)(D)(vii) and the Assurances Maintenance of Certification requirement for health IT developers to update and provide their Health IT Modules (§ 170.402(b)(3). We also established in § 170.402(b)(4) an Assurances Maintenance of Certification requirement for Predictive Decision Support Intervention transparency (89 FR 1371), and in section III.C.2 of this proposed rule, we propose to establish a conforming update to the Attestation Condition and Maintenance of Certification in § 170.406(a)(2) to address the adopted § 170.402(b)(4) DSI Maintenance of Certification requirement.</P>
                    <P>In addition to the Conditions and Maintenance of Certification requirements, in the ONC Cures Act Final Rule we established that ONC would enforce compliance with the 45 CFR subpart D Condition and Maintenance of Certification requirements (85 FR 25783). However, we also established ONC-ACB responsibilities (PoPCs). These responsibilities included the review and approval for submission of developers' § 170.406 attestations (§ 170.523(q)) and § 170.405 real world testing plans and results (§ 170.523(p)) (85 FR 25951). The ONC Cures Act Final Rule also established a PoPC in § 170.523(s) requiring ONC-ACBs to report any information that could inform whether ONC should exercise direct review of noncompliance with the Conditions and Maintenance of Certification requirements to ONC (85 FR 25783).</P>
                    <P>ONC-ACBs' PoPC responsibilities under the currently codified requirements in § 170.523(p) have encouraged and helped Program-participating developers to achieve a high rate of compliance with the real world testing Maintenance of Certification requirements in § 170.405. Under § 170.523(p), ONC-ACBs are required to confirm the completeness of developers' real world testing plans and results, and to confirm the developer timely submitted materials for public availability in accordance with § 170.405(b). We believe a similarly supportive dynamic exists for developers' compliance with attestations requirements in § 170.406 and insights reporting requirements in § 170.407, for which ONC-ACBs have explicitly aligned PoPC responsibilities as described in § 170.523(q) and (u).</P>
                    <P>
                        Informed by our experience with ONC-ACB support in monitoring and encouraging developers' compliance with certain 45 CFR 170 subpart D requirements over the past three years, and pursuant to the authority in PHSA 
                        <PRTPAGE P="63603"/>
                        section 3001(c)(5)(E) to “encourage compliance with the conditions of certification,” we now propose new ONC-ACB PoPC requirements in § 170.523 to encourage and support developers' compliance with Maintenance of Certification requirements in § 170.402 and 170.404. In parallel, we propose to update ONC-ACBs' responsibilities for conducting reactive surveillance in accordance with § 170.556(b) and working with developers to encourage remediation of observed non-conformities with Program requirements in § 170.556(d).
                    </P>
                    <P>Our proposal in § 170.556(b) would require ONC-ACBs to initiate surveillance when they become aware of facts or circumstances that would cause a reasonable person to question whether a health IT developer has satisfied certain Maintenance of Certification requirements. As a result of our proposals in § 170.556(b) and additional proposals in § 170.523(i), we are proposing to require ONC-ACBs perform reactive and randomized surveillance based on the specified Maintenance of Certification requirements in §§ 170.402(b)(1)-(4), 170.404(b)(1) and (2), 170.405(b)(1) and (2), 170.406(b), and 170.407(b). In case of non-conformities, we would require an ONC-ACB to notify health IT developers and require a CAP, in addition to the existing requirements in § 170.556 consistent with their accreditation under PoPCs in § 170.523(a) and ISO/IEC 17065. In § 170.556(d), we further propose revisions to the required elements of a CAP for identified non-conformities with respect to Program requirements codified in subpart D for which we propose an ONC-ACB would have responsibility under § 170.523. Under these proposals in § 170.523 and § 170.556, an ONC-ACB would have the duty to confirm a health IT developer's compliance with, and initiate surveillance whenever it becomes aware of each non-conformity to, the Maintenance of Certification requirements in §§ 170.402(b)(1)-(4), 170.404(b)(1) and (2), 170.405(b)(1) and (2), 170.406(b), and 170.407(b).</P>
                    <HD SOURCE="HD3">b. Updates to Principles of Proper Conduct for Maintenance of Certification Requirements</HD>
                    <P>In the ONC Cures Act Final Rule, we adopted Conditions and Maintenance of Certification requirements for health IT developers outlined in section 4002 of the Cures Act (85 FR 25717) and implemented them with further specificity in the Program, expressing initial and ongoing certification requirements for the health IT developers and their certified health IT products (85 FR 25718). We adopted certain responsibilities for the ONC-ACB's to ensure developers have met their obligations for certain Conditions and Maintenance of Certification requirements. We also provided that, if the monitoring processes implemented by ONC-ACBs are not adhered to by developers, the ONC-ACB, in accordance with Program reporting requirements, should follow its processes to institute a CAP. Should the developer fail to engage in the CAP process the ONC-ACB would alert ONC of the developer's failure to comply with the Conditions and Maintenance of Certification requirements (85 FR 25720 through 25721).</P>
                    <P>To ensure developers of health IT were meeting the requirements of the Program, we adopted requirements for ONC-ACBs in § 170.523. Specifically, we adopted PoPCs for ONC-ACBs in §§ 170.523(m), 170.523(p), 170.523(q), and 170.523(t) that aligned with certain Maintenance of Certification requirements, tasking ONC-ACBs to review and confirm certain information is submitted by health IT developers in response to the real world testing and attestation Maintenance of Certification requirements. ONC-ACBs are required to share additional information, as it relates to certain Maintenance of Certification requirements, with the National Coordinator regarding developer compliance with Program requirements (85 FR 25784 through 25785).</P>
                    <P>We now propose to expand an ONC-ACB's responsibilities to require additional oversight of certain Maintenance of Certification requirements be included in the ONC-ABC's surveillance reports and to provide certain documentation to the National Coordinator as part of its surveillance. We propose new PoPC requirements for ONC-ACBs specifically aligned to encourage transparency and support developers' compliance with Maintenance of Certification Requirements in 45 CFR part 170 subpart D, including redesignating § 170.523(p) through (u) as paragraphs (r) through (w). We propose to revise § 170.523(p) to add new requirements that ONC-ACBs verify and confirm a health IT developer's compliance with Attestation Maintenance of Certification requirements in accordance with § 170.402(b), and revise § 170.523(q) to add oversight requirements for developer compliance with API Maintenance of Certification requirements in accordance with § 170.404(b). Our proposed redesignation would mean the current requirements in § 170.523(p) real world testing, § 170.523(q) attestations, § 170.523(r) test results from ONC-ATLs, § 170.523(s) information for direct review, § 170.523(t) Health IT Module voluntary standards and implementation specifications updates notices, and § 170.523(u) insights would be shifted to § 170.523(r), (s), (t), (u), (v), and (w), respectively. We note that we do not propose to revise the requirements in proposed § 170.523(r), (s), (t), (u), (v) or (w) (currently codified as § 170.523(p), (q), (r), (s), (t), and (u), respectively).</P>
                    <P>Under these proposals in § 170.523, we would require that an ONC-ACB confirm and verify a health IT developer's compliance with the requirements in §§ 170.402(b)(1)-(4), 170.404(b)(1) and (2), 170.405(b)(1) and (2), 170.406(b), and 170.407(b) and, where a non-conformity rather than compliance is observed, to initiate surveillance in accordance with our proposals in § 170.556 (discussed in III.D.2.c below) and notify the health IT developer of each observed non-conformity. Each proposal in § 170.523(p) references a corresponding requirement for health IT developers in § 170.402(b), so that requirements in § 170.523(p)(1) references § 170.402(b)(1), our proposal for § 170.523(p)(2) references § 170.402(b)(2) and (b)(3), and our proposal for § 170.523(p)(3) references § 170.402(b)(4). Health IT developer requirements in § 170.404(b)(1) and (2) are also incorporated into our proposals for APIs in § 170.523(q). Similarly, the insights requirement in § 170.523(w) (finalized in the HTI-1 Final Rule as § 170.523(u) (89 FR 1435)) for ONC-ACBs was proposed and finalized simultaneously with corresponding developer requirements for Insights Condition and Maintenance of Certification requirements in § 170.407.</P>
                    <P>
                        We propose to limit the ONC-ACB oversight requirements to those certain Maintenance of Certification requirements mentioned above because of the administrative nature of these requirements (comparative to requiring, for example, investigation, analysis, or assessment). As stated above, ONC-ACBs already have responsibilities in § 170.523(p), (q), and (u) (which we propose to shift to § 170.523(r), (s), and (t), respectively) to verify and confirm that developers are meeting their obligations in §§ 170.405(b)(1) and (2), 170.406, and 170.407. These Maintenance of Certification requirements require developers to submit documentation to ONC-ACBs, notify ONC-ACBs when a non-
                        <PRTPAGE P="63604"/>
                        conformity arises during real world testing, and provide an attestation for compliance with certain certification criteria under the Program. We consider these obligations as strictly administrative, and their successful completion does not implicate developer behaviors that rise to the level of oversight that would be necessary for initial ONC review. Likewise, we consider the Maintenance of Certification requirements in §§ 170.402(b)(1)-(4) and 170.404(b)(1) and (2) to also be administrative in nature. We believe the proposed addition of § 170.402(b)(1)-(4) in § 170.523(p)(1)-(3) and § 170.404(b)(1) and (2) in § 170.523(q)(1) and (2) is suitable considering the ONC-ACBs experience with confirming and verifying that a developer has met the requirements in §§ 170.405(b)(1) and (2), 170.406, and 170.407.
                    </P>
                    <P>We note that we do not propose to include in § 170.523 the oversight of a health IT developer's compliance with the requirements in § 170.401, Information Blocking, and § 170.403(b), Communications Maintenance of Certification requirements. Unlike the requirements in § 170.402(b)(1)-(4) and § 170.404(b)(1) and (2), which we consider administrative, the oversight and enforcement of Information Blocking addresses practices that interfere with the access, exchange or use of EHI, and the Communications Maintenance of Certification requirements focuses on the update of agreements with clients that could limit ongoing collaboration and coordination. These Maintenance of Certification requirements compel developers to design, implement, and maintain business practices that align with ONC standards, facilitate data exchange, and actively engage in practices that ensure that their products remain compliant. Centralizing the oversight of these Maintenance of Certification requirements under ONC removes the possibility of having these conflicts, ensuring a standardized and consistent approach to enforcing these requirements.</P>
                    <P>While we consider the ONC-ACBs' Maintenance of Certification responsibilities as administrative, we also believe transparency is important regarding all Program requirements and propose to revise and add new PoPC surveillance reporting requirements for ONC-ACBs in § 170.523(i). As discussed, in § 170.556(b) and (d) we propose to add the Maintenance of Certification requirements proposed in § 170.523 to the ONC-ACBs' surveillance responsibilities. We propose that this responsibility would include initiating surveillance (§ 170.556(b)(2) and (3)), initiating CAP procedures (§ 170.556(d)(1)), initiating suspensions (§ 170.556(d)(5)) when a developer fails to engage with the CAP process for Maintenance of Certification non-conformities, and withdrawals (§ 170.556(d)(6)) when the health IT developer does not complete the actions necessary to reinstate the suspended certification (we refer readers to section III.D.2.c below for a discussion of these proposals). To better achieve transparency of the proposed surveillance activities, we propose to revise § 170.523(i)(2)(iii) to require ONC-ACBs, when conducting surveillance of certified health IT in accordance with their accreditation, to include the Maintenance of Certification requirements it surveilled in its quarterly surveillance results report.</P>
                    <P>We also propose to add a requirement in § 170.523(i)(4) that an ONC-ACB, as part of its responsibilities to conduct surveillance of certified health IT in accordance with its accreditation, and proposed requirements in § 170.556, shall notify the National Coordinator prior to initiating the suspension or withdrawal of a certification as specified in § 170.556 for a non-conformity pertaining to a Maintenance of Certification requirement for which the ONC-ACBs have responsibilities. We propose this revision because, as a common practice, ONC-ACBs notify ONC before suspending a certification for a certified Health IT Module when a developer fails to engage with the CAP process pertaining to a certification requirement non-conformity, and before withdrawing a certified Health IT Module when the health IT developer has not completed the actions necessary to reinstate the suspended certification. We propose to explicitly codify this practice for enforcement activities pertaining to certain Maintenance of Certification non-conformities.</P>
                    <P>To further our stated goals of increased transparency in the Program and encourage developer compliance, we also propose to add a new PoPC in § 170.523(x) “Reporting for non-compliance with approved corrective action plans.” We propose to require that ONC-ACBs report to ONC, pursuant to our proposal in § 170.556(d)(7)(ii), (discussed in detail in section III.D.2.c.iv below), the developer's failure to timely complete a CAP specific to a Maintenance of Certification requirement for which an ONC-ACB has specific responsibilities under § 170.523. We propose to require the ONC-ACBs to include all documentation pertaining to the identified non-conformity, including but not limited to the following information: (1) the Health IT Module and associated product(s); (2) the nature of the non-conformity(ies); (3) the corrective action plan documentation; (4) communications and records of proceedings; and (5) any additional information requested by ONC.</P>
                    <P>We believe the proposed required documentation in § 170.523(x) is necessary and valuable to support the National Coordinator's review of a health IT developer's actions or practices without requiring ONC to engage in duplicative fact-finding processes for applicable cases of non-conformities. The proposed documentation in § 170.523(x) would also inform the National Coordinator on whether the ONC-ACB met their obligations to notify the developer of the non-conformity and initiate corrective action procedures under §§ 170.523 and 170.556. Furthermore, requiring the proposed stated documentation would provide clarity and consistency for developers of health IT and ONC-ACBs on our expectations for the degree of accuracy and detail required for documenting a non-conformity with a Maintenance of Certification requirement for which an ONC-ACB has specific responsibilities under § 170.523. The documentation requirements would also help construct an accurate record that could inform whether the National Coordinator should exercise direct review under § 170.580(a).</P>
                    <P>Lastly, in § 170.523(i)(1), as part of an ONC-ACBs obligations to conduct surveillance of certified health IT in accordance with its accreditation and § 170.556, ONC requires ONC-ACBs to submit an annual surveillance plan to the National Coordinator. The ONC-ACBs submit their annual plans in September with an effective date of January 1 in the following year. As such, if we adopt the Maintenance of Certification requirements proposals in §§ 170.523 and 170.556, ONC-ACBs would need to include them as part of their annual surveillance plans for January 1, 2026.</P>
                    <P>We welcome comments on these proposals.</P>
                    <HD SOURCE="HD3">c. Updates to Surveillance for Maintenance of Certification Requirements</HD>
                    <P>
                        In the 2015 Edition Final Rule, we finalized that CAP requirements applied across-the-board to all types of surveillance and confirmed non-conformities (80 FR 62714). We reiterated that our goal for surveillance requirements was to ensure that health IT users, implementers, and purchasers 
                        <PRTPAGE P="63605"/>
                        would be alerted to potential non-conformities in a timely and effective manner, consistent with the patient safety, program integrity, and transparency objectives described in the 2015 Edition Proposed Rule (80 FR 62716 through 62717). We received support from commenters to specify certain required elements and procedures for CAPs (80 FR 62716). We also finalized reporting requirements for CAPs and extended these requirements to all cases in which an ONC-ACB confirms a non-conformity and subsequently approves a CAP (80 FR 62717).
                    </P>
                    <P>We continued to build upon surveillance and CAP requirements by adopting the ONC direct review regulatory framework in the EOA Final Rule (81 FR 72468 through 72471), which permits the Program to provide enhanced oversight for safety and health IT developer accountability. The EOA Final Rule emphasized the importance of protecting public health and safety while also strengthening transparency and accountability in the Program. Following the EOA Final Rule, in the ONC Cures Act Final Rule we addressed enforcement processes for new requirements established in the Cures Act. Section 4002(a) of the Cures Act adds (in section 3001(c)(5)(D) of the PHSA) Program requirements aimed at addressing health IT developers' actions and business practices through the Conditions and Maintenance of Certification requirements, which expanded the focus of the Program requirements beyond the certified health IT itself (85 FR 25648 through 25649). Equally important, section 4002(a) of the Cures Act also provides (in section 3001(c)(5)(E) of the PHSA) that the Secretary may encourage compliance with the Conditions and Maintenance of Certification requirements and take action to discourage noncompliance. In the ONC Cures Act Final Rule, we, therefore, finalized an enforcement framework for the Conditions and Maintenance of Certification requirements in §§ 170.580 and 170.581 to encourage consistent compliance with the requirements. More specifically, we finalized processes in § 170.580 for ONC to review potential or known instances where a Condition or Maintenance of Certification requirement under the Program has not been met or is not being met by a health IT developer. We also finalized in §§ 170.580 and 170.581 requirements to utilize the processes previously established for ONC direct review of certified health IT in the enforcement of the Conditions and Maintenance of Certification requirements.</P>
                    <P>
                        We noted that the new Conditions and Maintenance of Certification requirements in section 4002 of the Cures Act focus on the actions and business practices of health IT developers (
                        <E T="03">e.g.,</E>
                         information blocking and appropriate access, use, and exchange of electronic health information) as well as technical interoperability of health IT (
                        <E T="03">e.g.,</E>
                         APIs and real world testing) (85 FR 25782 through 25783). When we originally distinguished between the Conditions and Maintenance of Certification requirements that focus on actions and business practices of health IT developers versus technical interoperability of health IT, we did not further distinguish exclusively administrative functions that are required of a health IT developer to meet certain Maintenance of Certification requirements in part 170 subpart D. Rather, we determined that ONC should be responsible for addressing non-conformities pertaining to all Maintenance of Certification requirements (85 FR 25782 through 25783). We also clarified that ONC-ACBs are not responsible for enforcement of the Conditions and Maintenance of Certification requirements, and that they must report any information that could inform whether ONC should exercise direct review of noncompliance with the Conditions and Maintenance of Certification requirements to ONC. We noted that ONC-ACBs also address non-conformities with technical and other Program requirements through surveillance and by working with health IT developers through CAPs. We stressed that, as finalized in the EOA Final Rule (81 FR 72427 through 72428) and per § 170.580(a)(3)(v), ONC may refer the applicable part of its review of certified health IT to the relevant ONC-ACB(s) if ONC determines this would serve the effective administration or oversight of the Program (85 FR 25785).
                    </P>
                    <P>Since publication of the ONC Cures Act Final Rule, we now have enforcement experience with Maintenance of Certification requirements in 45 CFR 170 subpart D. More specifically, ONC conducted 13 direct reviews in 2023, of which 10 were in connection to the non-conformity to the API Maintenance of Certification requirement in § 170.404(b)(3) for failure to comply with the rollout of § 170.315(g)(10); two for failure to submit their real world testing results leading to a non-conformance with § 170.406(b)(2); and, one for failure to submit their annual attestation related to § 170.406(b). We have conducted multiple direct reviews of non-conformities specific to developers of certified health IT missing a document-submission or other deadline for Maintenance of Certification requirements in 45 CFR 170 subpart D. During these direct reviews, we have coordinated with the ONC-ACBs the corrective actions and communications with the developers. Based on this enforcement experience, we have found that some non-conformities specific to certain Maintenance of Certification requirements may be better and more quickly resolved without immediate ONC involvement in certain cases and are better suited to initial oversight by the ONC-ACBs.</P>
                    <P>
                        With this experience, we recognize that ONC-ACBs are equally well suited to conduct surveillance and work with developers of certified health IT through CAPs to remedy non-conformities beyond certification requirements in 
                        <E T="03">certain circumstances.</E>
                         We no longer believe that keeping enforcement for certain Maintenance of Certification requirements exclusively within ONC oversight benefits the Program and could, in fact, result in Program inefficiencies to the detriment of the Program, users of certified health IT, and developers of certified health IT. The inclusion of certain Maintenance of Certification requirements within ONC-ACB oversight would increase transparency and result in more expedient determinations of whether a non-conformity exists, along with its resolution. In our experience, the collaboration between ONC-ACBs, health IT developers of certified health IT, and users in examining potential non-conformities, along with ONC-ACB's oversight of specific Maintenance of Certification requirements, facilitates quicker resolutions leading to more efficiency in the Program. This efficiency stems from the ONC-ACBs' capacity to engage and communicate with developers promptly as well as their extensive expertise in surveilling certified Health IT Modules for continued conformity to the requirements of their certifications.
                    </P>
                    <HD SOURCE="HD3">i. Reactive Surveillance</HD>
                    <P>
                        We propose to revise the reactive surveillance requirements in § 170.556(b) to account for the specified Maintenance of Certification requirements in subpart D for which an ONC-ACB would have oversight pursuant to revisions to § 170.523. We propose in § 170.556(b) to require an ONC-ACB to initiate surveillance (including, as necessary, in-the-field 
                        <PRTPAGE P="63606"/>
                        surveillance required by paragraph (a) of this section) whenever it becomes aware of facts or circumstances that would cause a reasonable person in the ONC-ACB's position to question one or more of the following: (1) a certified Health IT Module's continued conformity to the requirements of its certification; (2) a developer's satisfaction of the Maintenance of Certification requirements in § 170.402(b)(1); and (3) an applicable developer's satisfaction of the Maintenance of Certification requirements for which an ONC-ACB has a responsibility under § 170.523 to confirm compliance.
                    </P>
                    <P>We propose the surveillance requirements for the Maintenance of Certification requirements in § 170.556(b)(2) and (3) as two distinct elements because of the diverse obligations in 45 CFR part 170 subpart D that health IT developers must satisfy to remain in compliance with the Program. To ensure health IT developer accountability, and as discussed above, we have adopted the Maintenance of Certification requirements in part 170 subpart D to express ongoing requirements for health IT developers and their applicable Health IT Module(s) certified to specific certification criteria. The Maintenance of Certification requirements in 45 CFR part 170 subpart D do not always apply to all health IT developers participating in the Program. The Program is voluntary and health IT developers may certify their Health IT Module(s) to one, some, or all the certification criteria adopted by the Secretary, and they are not required to certify their Health IT Module(s) to every certification criterion to participate in the Program. Also as discussed in the previous section, we propose in § 170.523(p)(1) that ONC-ACBs confirm that health IT developers retain all records and information necessary to demonstrate initial and ongoing compliance with the requirements of the Program in accordance with § 170.402(b)(1). Our proposal in § 170.523(p)(1) would require ONC-ACBs to confirm that health IT developers are meeting the requirements in § 170.402(b)(1) and, in the proposed § 170.523(i)(2)(iii), we would require the ONC-ACBs to conduct surveillance of the Maintenance of Certification requirements and include the results in its quarterly report to the National Coordinator, in accordance with its accreditation and § 170.556(a) and (e)(1). To support the PoPC proposals in § 170.523, our proposal in § 170.556(b)(2) would require an ONC-ACB to initiate surveillance (including, as necessary, in-the-field surveillance) whenever it becomes aware of facts or circumstances that would cause a reasonable person in the ONC-ACB's position to question a developer's satisfaction of the Maintenance of Certification requirements in § 170.402(b)(1). The proposed requirements in § 170.523(i)(2)(iii) and in § 170.523(p)(1), taken together with our proposal in § 170.556(b)(2), would result in the ONC-ACB initiating and conducting surveillance of a health IT developers' satisfaction of its obligations in § 170.402(b)(1).</P>
                    <P>Similar to our proposal in § 170.523(p)(1), we propose in § 170.523(p)(2) and (3), 170.523(q), (r), (s), and (w) to require the ONC-ACBs to confirm health IT developers are meeting their obligations, as applicable, under the Maintenance of Certification requirements in §§ 170.402(b)(2)-(4), 170.404(b)(1) and (2), 170.405(b)(1) and (2), 170.406(b), and 170.407(b); and in § 170.523(i)(2)(iii) to conduct surveillance of the Maintenance of Certification requirements listed in § 170.523, in accordance with their accreditation and § 170.556(b)(3). To help meet these obligations, for the proposed requirement in § 170.556(b)(3), we propose to require an ONC-ACB to initiate surveillance (including, as necessary, in-the-field surveillance) when it becomes aware of facts or circumstances that would cause a reasonable person in its position to question an applicable developer's satisfaction of the Maintenance of Certification requirements for which an ONC-ACB has a responsibility under § 170.523 (that is, §§ 170.402(b)(2)-(4), 170.404(b)(1) and (2), 170.405(b)(1) and (2), 170.406(b), and 170.407(b)).</P>
                    <P>Overall, the proposals in § 170.556(b)(2) and (3) would mean that as part of the requirement to confirm a health IT developer met its obligation(s) in part 170 subpart D, an ONC-ACB must initiate surveillance when it reasonably finds a health IT developer failed to meet the Maintenance of Certification subpart D requirements for which the ONC-ACB would have oversight of in § 170.523. We propose to distinguish between the proposed requirements in § 170.556(b)(2) and (3) because all health IT developers participating in the Program are required to comply with requirements in § 170.402(b)(1), whereas only health IT developers with Health IT Modules certified to those certification criteria listed in the requirements in §§ 170.402(b)(2)-(4), 170.404(b)(1) and (2), 170.405(b)(1) and (2), 170.406(b), and 170.407(b) are required to comply with the applicable Maintenance of Certification requirements. Given these considerations and our proposal to expand ONC-ACB oversight of specific Maintenance of Certification requirements listed in § 170.523, we propose to include requirements that ONC-ACBs must initiate surveillance of the specified Maintenance of Certification requirements in § 170.556(b)(2) and (3) reactive surveillance whenever it becomes aware of facts or circumstances that would cause a reasonable person in the ONC-ACB's position to question a developer's satisfaction of its obligations under 45 CFR part 170 subpart D.</P>
                    <P>Additionally, we propose to revise § 170.556(b)(1) by moving the current verification requirements of § 170.523(k) listed in § 170.556(b)(1) to be part of § 170.556(b)'s overall language. Our proposal would not change or modify the ONC-ACBs' current responsibilities to initiate in-the-field-surveillance requirements in § 170.556(a) or the randomized surveillance considerations in § 170.556(c).</P>
                    <P>We welcome comments on these proposals.</P>
                    <HD SOURCE="HD3">ii. Corrective Action Plan and Procedures</HD>
                    <P>
                        In the 2015 Edition Final Rule, we adopted requirements in § 170.556(d)(1) that require an ONC-ACB to notify a developer when it determines that a non-conformity exists and require the developer to submit a proposed CAP for the applicable certification criterion, certification criteria, or certification requirement (80 FR 62758). We propose to revise the corrective action plan and procedures in § 170.556(d)(1) to include the Maintenance of Certification requirements specified in subpart D for which we propose an ONC-ACB would have responsibilities for under § 170.523 (discussed in the section III.D.2.b above). We expect the ONC-ACB to initiate surveillance as necessary to assess whether the developer has met the Condition and Maintenance of Certification requirements obligations under subpart D of part 170—for which we propose the ONC-ACB to have oversight responsibilities—in the same manner as it initiates surveillance for other Program requirements. We propose to require that an ONC-ACB notify the developer of health IT, when an ONC-ACB determines, through surveillance under § 170.556 or otherwise, that the health IT developer is out of compliance with the specified Maintenance of Certification requirement and to require the developer submit a proposed CAP for the applicable Maintenance of Certification requirement.
                        <PRTPAGE P="63607"/>
                    </P>
                    <P>In addition to the corrective action procedures adopted in the 2015 Edition Final Rule, ONC also specified certain baseline required elements for CAPs in § 170.556(d)(3) (80 FR 62758 through 62759). Specifically, we finalized in § 170.556(d)(3)(i)-(vi) six minimum required elements that an ONC-ACB must verify are included in the CAP submitted by the developer of health IT. We now propose to revise § 170.556(d)(3), which requires the ONC-ACB to verify the elements of the CAP, to account for the proposed addition of certain Maintenance of Certification requirements that we propose an ONC-ACB must include in its surveillance activities.</P>
                    <P>We do not find all existing CAP requirements equally necessary for non-conformities that involve the proposed new responsibilities for ONC-ACBs to initiate corrective procedures for specified subpart D Maintenance of Certification requirements, we also propose to specify different minimum required CAP elements based on the type of non-conformity the plan addresses. We believe that establishing certain minimum expectations and procedures for initiating CAP procedures for specified subpart D Maintenance of Certification requirements would provide ONC-ACBs, as well as health IT developers and users, with greater clarity and predictability regarding this aspect of the Program. Furthermore, ONC-ACBs have unique experience working directly with developers to remedy identified non-conformities to the requirements of certification codified in subparts A, B, C, and E, as well as verifying and confirming a developer has met its obligations with the Maintenance of Certification requirements for real world testing and attestations. This experience translates well to having ONC-ACBs conduct surveillance for certain Maintenance of Certification requirements for which we propose the ONC-ACBs have specific responsibilities. We note that our expectations regarding an ONC-ACBs' surveillance responsibilities specific to the oversight and enforcement requirements of certification would not change with the addition of certain Maintenance of Certification requirements under our revisions and additions proposed in § 170.556(b) reactive surveillance and (d) corrective action plan and procedures.</P>
                    <P>To better differentiate the requirements for each CAP, in § 170.556(d)(3)(i), we propose to list the minimum required elements for all CAPs pertaining to all non-conformities. In § 170.556(d)(3)(ii), we propose to list the minimum required elements for non-conformities with respect to any Program requirement codified in subparts A, B, C, or E of part 170. In § 170.556(d)(3)(iii), we propose to list the minimum required elements for non-conformities with respect to any Program requirement codified in subpart D of this part for which the ONC-ACBs would have responsibility under § 170.523. We discuss each proposed list of elements in detail in the following paragraphs.</P>
                    <P>We are retaining in § 170.556(d)(3) the currently required elements for identified non-conformities with respect to any Program requirements codified in subparts A, B, C, or E with proposed restructuring of the paragraph levels and minor proposed modifications. For the currently codified CAP elements, we propose to move the requirements in § 170.556(d)(3)(i), (v), and (vi) to § 170.556(d)(3)(i)(A), (B), and (C), respectively. We also propose to shift the currently codified CAP elements in § 170.556(d)(3)(ii), (iii), and (iv) to § 170.556(d)(3)(ii)(A), (B), and (C), respectively. The proposed revised elements are substantially the same elements currently codified in § 170.556(d)(3)(i)-(vi), and we do not propose revisions to the regulatory text in the newly shifted § 170.556(d)(3)(i)(A), (B), and (C) or § 170.556(d)(3)(ii)(A). For these elements, we only propose to revise the level of paragraphs.</P>
                    <P>To account for the proposed shifting of elements and the addition of the Maintenance of Certification to the ONC-ACBs' oversight responsibilities, we propose to revise paragraph (d)(3)(i) to specify that for each identified non-conformity with respect to any Program requirement, the ONC-ACB must verify that the associated CAP includes the following, at a minimum: a description of the identified non-conformities (§ 170.556(d)(3)(i)(A)); the timeframe under which corrective action will be completed (§ 170.556(d)(3)(i)(B)); and, an attestation by the developer that it has completed all elements of the approved CAP (§ 170.556(d)(3)(i)(C)). The proposed required elements would apply to proposed CAPs that aim to remedy identified non-conformities for a certified Health IT Module that does not conform to the applicable requirements of its certification and/or when the health IT developer is out of compliance with Maintenance of Certification requirements specified in subpart D of this part for which the ONC-ACB has specific responsibilities under § 170.523. We propose to require the minimum required elements in § 170.556(d)(3)(i)(A), (B), and (C) because we believe that certain elements should serve as the baseline of information for any type of non-conformity the CAP addresses.</P>
                    <P>We also believe certain minimum required elements should still apply regarding non-conformities with respect to any Program requirement codified in subparts A, B, C, or E of part 170. To account for our restructuring of the current minimum six elements in § 170.556(d)(3), in § 170.556(d)(3)(ii), we propose to shift and revise the other three remaining minimum required elements in paragraphs (d)(3)(ii), (iii), and (iv) as § 170.556(d)(3)(ii)(A), (B), and (C). For a Health IT Module that does not conform to the certification requirements codified in subparts A, B, C, or E of part 170, we propose in § 170.556(d)(3)(ii) that for each CAP submitted by the developer, the ONC-ACB shall verify the CAP includes the required elements specified in proposed § 170.556(d)(3)(ii)(A) through (C), in addition to the proposed required elements identified in § 170.556(d)(3)(i)(A), (B) and (C). We note that these proposed three minimum required elements are the same three minimum required elements that are codified in § 170.556(d)(3)(ii)-(iv), with proposed minor modifications. We propose to distinguish the elements in this way to account for the proposed elements identified in § 170.556(d)(3)(iii)(A) and (B) that we would not require for CAPs pertaining to non-compliance with the certification requirements codified in subparts A, B, C, and E of part 170.</P>
                    <P>The proposed elements listed in § 170.556(d)(3)(ii)(A) through (C) are substantially the same elements currently codified in § 170.556(d)(3)(ii) through (iv), with proposed minor modifications. For clarity, we propose to revise the proposed CAP element identified in § 170.556(d)(3)(ii)(B) (currently designated in § 170.556(d)(3)(iii)). We clarify that this required element for CAPs does not mean that on-site surveillance at a deployed site is the only means through which an ONC-ACB could identify a technical non-conformity. Thus, we propose in § 170.556(d)(3)(ii)(B) that the ONC-ACBs may identify a technical non-conformity at any location where surveillance procedures have been conducted resulting in an identified non-conformity, and for all other potentially affected customers and users.</P>
                    <P>
                        We also propose a minor revision in § 170.556(d)(3)(ii)(C) (currently codified in § 170.556(d)(3)(iv)) to improve the readability of the required element. We note that in § 170.556(d)(3)(ii)(C), part of 
                        <PRTPAGE P="63608"/>
                        the CAP required element addresses how the developer will ensure that all affected, and potentially affected customers and users are alerted to the identified non-conformities, including a detailed description of how the developer will assess the scope and impact of the problem and identify all potentially affected customers. We clarify our expectation with this requirement is two pronged. Satisfying the element would include (1) how the health IT developer identifies the potentially affected customers and (2) identifying who is the actual affected customer(s) by including a detailed description of how the health IT developer will promptly ensure that all potentially affected customers are notified of the non-conformity and plan for resolution. During the CAP process, an ONC-ACB instructs the developer to submit a proposed CAP, or a revised proposed CAP, to remedy the non-conformity. The ONC-ACB also verifies the attestation by the developer that it has completed all elements of the approved CAP (§ 170.556(d)(3)(i)(C)). We believe requiring developers to identify affected customers during the CAP approval process as part of the element in § 170.556(d)(3)(ii)(C) is helpful for several reasons, most notably that it aligns with the requirements in our enforcement mechanisms in § 170.580. It would also be useful information when we need to verify communications with a customer(s), as well as aid with Federal agency coordination by identifying the names and the number of affected customers who participate in other HHS programs. We welcome comment on our expectations and whether we should consider codifying this element as two separate requirements.
                    </P>
                    <P>Recognizing the diversity of non-conformities, we propose, in § 170.556(d)(3)(iii), different required minimum elements for CAPs submitted for addressing non-compliance with Maintenance of Certification requirements specified in subpart D. We propose to require that an ONC-ACB verify that the proposed minimum required elements in § 170.556(d)(3)(i)(A), (B), and (C) are included in a CAP pertaining to Maintenance of Certification requirements. Additionally, to better address the variations in types of non-conformities to Program requirements, we propose in § 170.556(d)(3)(iii)(A) and (B) to implement specific required elements for each identified non-conformity with respect to any Program requirement codified in subpart D of this part for which the ONC-ACB has responsibilities under § 170.523 of this part (we refer readers to section III.D.2.b for a list of these proposed responsibilities in § 170.523). Thus, for all Maintenance of Certification requirement non-conformities, an ONC-ACB must verify that a CAP includes the proposed elements identified in § 170.556(d)(3)(iii)(A) and (B), in addition to the three minimum required elements identified in § 170.556(d)(3)(i)(A), (B), and (C).</P>
                    <P>The proposed required elements identified in § 170.556(d)(3)(iii)(A) and (B) would require ONC-ACBs to confirm how the developer will address and resolve identified non-conformities with Maintenance of Certification requirements for which the ONC-ACBs have responsibilities under proposed § 170.523. We propose to set forth different elements in § 170.556(d)(3)(iii)(A) and (B) for CAPs addressing non-conformities with certain Maintenance of Certification requirements because of the administrative nature of these requirements compared to, for example, the certification requirements of subparts A, B, C. The elements in § 170.556(d)(3)(iii)(A) and (B) enhance the process for developers to regain compliance with the Maintenance of Certification requirements in several ways. The proposal in § 170.556(d)(3)(iii)(A) would require a developer to outline the actions needed to address non-conformities related to Maintenance of Certification requirements, providing clarity in addressing the non-conformity; while the requirement in § 170.556(d)(3)(iii)(B) underscores the importance of ensuring comprehensive resolution for all identified non-conformities specific to the Maintenance of Certification requirements. These elements will aid developers in crafting CAPs tailored to the distinct challenges posed by Maintenance of Certification requirements, contributing to a clearer regulatory framework. By specifying actions related to Maintenance of Certification requirements, the elements offer explicit requirements, reduce ambiguity, and align requirements with the regulatory intent of maintaining industry-wide compliance and quality standards. This specificity supports ONC-ACBs' effective oversight, allowing them to assess the adequacy and thoroughness of CAPs and ensuring ongoing compliance with certification requirements. We welcome comments on these proposals.</P>
                    <HD SOURCE="HD3">iii. Additional Optional Elements</HD>
                    <P>The proposed minimum CAP elements in § 170.556(d)(3)(i)—(iii) should be seen as a starting point and represent a minimum, and not a limit, on the elements that may be required by the ONC-ACBs. In other words, with the proposed changes to CAP minimum element specifications, an ONC-ACB may require that a developer include additional elements in any given CAP beyond those that would be the minimum required under § 170.556(d)(3), as proposed. This flexibility is consistent with prior surveillance requirements, and we would continue to give ONC-ACBs substantial flexibility and discretion to decide how to implement these requirements as part of their overall approach to surveillance (80 FR 16880). Such flexibility is important for minimizing the burden of surveillance on all interested parties, while ensuring that an ONC-ACB can approach surveillance in a way that effectively encourages and supports developers' successful correction of non-conformities with Program requirements. Accordingly, we also propose to revise § 170.556(d) by adding § 170.556(d)(3)(iv) to allow an ONC-ACB to require that the CAP include elements beyond those specified in proposed § 170.556(d) as the minimum.</P>
                    <P>Table 1C below includes the proposed revised elements described in this rule that an ONC-ACB would be required to verify in a CAP.</P>
                    <GPH SPAN="3" DEEP="259">
                        <PRTPAGE P="63609"/>
                        <GID>EP05AU24.002</GID>
                    </GPH>
                    <P>To aid readers, we offer the following scenario to illustrate the required elements in a CAP that an ONC-ACB must verify based on the specific Program requirements implicated by each identified non-conformity. We note that this scenario is merely illustrative, and the outcomes provided in this scenario are hypothetical. The outcome of this scenario should not be construed as legal precedent for similarly situated fact patterns.</P>
                    <HD SOURCE="HD3">Scenario</HD>
                    <P>The ONC-ACB receives signals indicating a potential non-conformity, sourced from user complaints, adverse event reports, or routine surveillance activities. Upon detecting possible certification criteria non-conformities within the certified Health IT Module of a developer, the ONC-ACB initiates surveillance to address the § 170.315(b) requirements. During this surveillance, the ONC-ACB receives information indicating the developer may have failed to submit a real world testing plan that demonstrates compliance to the full scope of the applicable certification criteria and functions requirements, including § 170.315(b). A certified Health IT Module that fails to successfully demonstrate full compliance of certification capabilities is treated as any other observation of a failure to meet specific Program requirements. As a result, the ONC-ACB also initiates a second surveillance, this time to address the § 170.405(b)(1) real world testing plan.</P>
                    <P>Once the surveillance activities substantiate non-conformity(ies), the ONC-ACB notifies the developer of its findings and requires the developer to produce a proposed CAP addressing the identified issues, such as interoperability challenges, ineffective decision support, delayed updates, and outdated documentation.</P>
                    <P>Because the ONC-ACB has identified a non-conformity pertaining to Maintenance of Certification requirements in § 170.405(b), the ONC-ACB must verify the CAP includes the proposed required elements identified in § 170.556(d)(3)(i)(A), (B), (C), and § 170.556(d)(3)(iii)(A) and (B). The CAP outlines a step-by-step approach and timeline for the developer to address the non-conformities. The ONC-ACB would require, under the proposed elements in § 170.556(d)(3), that the CAP address the non-conformity with § 170.315(b) and include the required elements in § 170.556(d)(3)(i)(A) through (C); and § 170.556(d)(3)(ii)(A) through (C) as it pertains to a non-conformity for subparts A, B, C, or E of this part. The ONC-ACB may also require the developer to include elements in the CAP beyond those specified in proposed § 170.556(d) as the minimum required elements, according to the proposed addition of § 170.556(d)(3)(iv).</P>
                    <P>With the ONC-ACBs guidance, the developer is able to provide an acceptable proposed CAP to the ONC-ACB addressing the two identified non-conformities, who verifies all the required elements to ensure effective resolution of the identified non-conformities and approves them. The CAP provides a roadmap for the developer to rectify real world testing Maintenance of Certification non-conformities, enhance interoperability, optimize decision support features, ensure timely updates, and update documentation and training materials.</P>
                    <P>The ONC-ACB continues its monitoring of the certified Health IT Module, including implementation of the CAP and progress towards resolution of the non-conformities. Follow-up assessments may be scheduled to confirm sustained compliance, aligning with the ONC-ACB's commitment to continuous improvement in the EHR system's reliability and adherence to certification criteria. The ONC-ACB ensures successful resolution of identified non-conformities and confirms that the Health IT Module now complies with all applicable certification criteria and Maintenance of Certification requirements for real world testing.</P>
                    <HD SOURCE="HD3">iv. Suspension, Withdrawals, and Notification Procedures</HD>
                    <P>
                        In some circumstances, despite an ONC-ACB's effort to engage and encourage the developer, a developer's non-conformity with Maintenance of Certification or other Program requirements may not be successfully addressed. Under existing regulations, ONC-ACBs shall initiate suspension procedures for a Health IT Module for the following reasons: a developer does not submit a proposed CAP in the 
                        <PRTPAGE P="63610"/>
                        allotted time (§ 170.556(d)(5)(i)); a developer does not submit a revised proposed CAP within the allotted time resulting in the ONC-ACB being unable to approve a CAP (§ 170.556(d)(5)(ii)); and, if the developer does not complete the corrective actions specified in the approved CAP (§ 170.556(d)(5)(iii)). We propose to revise § 170.556(d)(5) to require that an ONC-ACB to initiate suspension procedures where a developer fails to propose a CAP, fails to propose an acceptable CAP, or fails to successfully complete an approved CAP for identified non-conformities with respect to those Maintenance of Certification requirements for which an ONC-ACB would have PoPC and surveillance responsibilities. This proposal would be a parallel complement to the existing requirement for an ONC-ACB to initiate suspension procedures for analogous failures of corrective action procedures to successfully resolve non-conformities of a Health IT Module to the requirements of its certification.
                    </P>
                    <P>We note that under current requirements in § 170.556(d)(6), which we do not propose to substantively revise in this proposed rule, if a certified Health IT Module's certification has been suspended, then an ONC-ACB is permitted to initiate certification withdrawal procedures for the Health IT Module (consistent with its accreditation to ISO/IEC 17065 and procedures for withdrawing a certification) when the health IT developer has not completed the actions necessary to reinstate the suspended certification. Therefore, if an ONC-ACB initiates suspension procedures in accordance with proposed § 170.556(d)(5) with respect to an identified non-conformity for a Program requirement codified in subpart D for which the ONC-ACB has responsibilities under § 170.523, it may initiate certification withdrawal procedures in accordance with § 170.556(d)(6).</P>
                    <P>While the Maintenance of Certification requirements pertain to developer behaviors, we consider the specific Maintenance of Certification requirements that an ONC-ACB would have for PoPC and surveillance responsibilities to be entirely administrative in nature. The ONC-ACBs would not make a determination to suspend or withdraw certification based on developer behavior, such as non-compliance with information blocking requirements as specified in § 170.401. Instead, the ONC-ACB would carry out its obligations specified in § 170.556(d)(5) and (6) in response to a developer's failure to meet the CAP related to administrative and routine activities such as submitting a real world testing plan on time. Furthermore, ONC-ACBs and developers have experience with initiating suspensions and withdrawals for developers who fail to engage in the CAP process pertaining to certification non-conformities, and we anticipate that the ONC-ACBs could transition to applying § 170.556(d)(5) and (6) procedures to the proposed CAP procedures for Maintenance of Certification non-conformities without much additional effort. Developers too are also familiar with the process so we expect engaging in the suspension and withdrawal processes for Maintenance of Certification non-conformities would not place much additional burden on them.</P>
                    <P>We note that delegating suspensions and withdrawal responsibilities to ONC-ACBs for Maintenance of Certification non-conformities would not mean the National Coordinator does not have authority to review ONC-ACB action(s). As discussed in detail in the section III.D.2.b, we propose to revise the PoPCs to add a requirement in § 170.523(iii)(4) that ONC-ACBs must notify the National Coordinator prior to initiating a suspension or withdrawal as specified in § 170.556 for a non-conformity pertaining to a Maintenance of Certification requirement for which the ONC-ACBs have responsibilities. We also note in § 170.580(a)(3)(ii) that ONC may assert exclusive review of certified health IT as to any matters under review by ONC, and any similar matters under surveillance by an ONC-ACB.</P>
                    <P>While we believe that ONC-ACBs are well suited to conducting surveillance and coordinating with developers of certified health IT to resolve certain Maintenance of Certification requirement non-conformities, we also acknowledge that there may be instances when a developer fails to timely submit an acceptable proposed CAP or complete an approved CAP, despite an ONC-ACBs efforts to gather and verify this information. In these instances, we believe it is necessary for an ONC-ACB to notify the National Coordinator that a developer failed to submit or complete a CAP addressing these specific Maintenance of Certification non-conformities so that the National Coordinator may review the information and proceed accordingly. Therefore, we propose to add, as paragraph (d)(7) of § 170.556, new requirements for an ONC-ACB to report specific information to ONC when a developer fails to timely submit or complete an approved CAP. This proposal would apply to an identified non-conformity with respect to any Program requirement codified in subpart D for which the ONC-ACB has responsibilities under § 170.523.</P>
                    <P>Under the proposal in § 170.556(d)(7), we would require an ONC-ACB to notify the National Coordinator when the ONC-ACB's requirement to initiate suspension procedures is triggered by the developer's failure to engage (successfully or failure to engage at all, as applicable) with the CAP process for a non-conformity to a Maintenance of Certification requirement. Specifically, we propose in § 170.556(d)(7)(i) that an ONC-ACB must immediately notify the National Coordinator if one or more of the following occurs: 1) the developer has not submitted a proposed CAP; 2) the ONC-ACB cannot approve a CAP because the developer has not submitted a revised proposed CAP; or 3) the developer has not completed the corrective actions specified by an approved CAP within the time specified therein. We propose this requirement to strengthen transparency within the Program as well as encourage developer compliance with the Program. Additionally, this information would inform the National Coordinator whether the ONC-ACB met its obligations to notify the developer of the surveillance activity, if there was an identified non-conformity, and how to remediate the non-conformity, including guidance on the required elements in the CAP, as well as the developer's response and level of engagement with the CAP process.</P>
                    <P>To further accomplish our goal of increased transparency and encouraging developer compliance, we propose in § 170.556(d)(7)(ii) that an ONC-ACB must report certain information to ONC when a developer fails to submit a proposed CAP that can be approved, or complete an approved CAP with respect to any Program requirement codified in subpart D for which an ONC-ACB has responsibilities under § 170.523. We propose to add the requirement that an ONC-ACBs shall report the information specified in § 170.523(x) (discussed in section III.D.2.b above) to the National Coordinator pursuant to the requirements specified in § 170.556(d)(7)(i), and we propose to add the requirement in § 170.556(d)(7)(ii)(A) that an ONC-ACBs must notify the developer immediately when an ONC-ACB begins the notification procedures in § 170.556(d)(7)(i).</P>
                    <P>
                        Lastly, we propose to revise 45 CFR 170.556 to correct regulatory text errors. First, we propose to revise § 170.556(d)(6) by removing the “or” 
                        <PRTPAGE P="63611"/>
                         within the description of “Withdrawal” because this was a typographical error. We also propose to revise § 170.556(e)(3) by removing the reference to § 170.523(f)(2)(xi). In the ONC Cures Act Final Rule, § 170.523(f)(2) was removed and reserved. Therefore, we propose to remove this reference from § 170.556(e)(3) to correct this technical error.
                    </P>
                    <P>We welcome comment on these proposals.</P>
                    <HD SOURCE="HD3">3. Updates to Principles of Proper Conduct for API Discovery Details</HD>
                    <P>In the ONC HTI-1 Final Rule, we finalized requirements in § 170.404(b)(2) for Certified API Developers to publish certain service base URLs and related organization details in a standardized FHIR® format (89 FR 1287). This included a requirement, in § 170.404(b)(2)(iii)(B), that Certified API Developers review this information quarterly and update it as necessary.</P>
                    <P>We propose a conforming policy, applicable to ONC-ACBs beginning January 1, 2027, to support the regular reporting of API discovery details including service base URLs and related organization details according to our proposed requirements in § 170.404(b)(2) and (3) (see elsewhere in this preamble at III.B.2, III.B.3, III.B.15, and III.B.20.d our proposals for revising § 170.404(b)(2)). Specifically, we propose to add a new paragraph in § 170.523(m)(6) to require ONC-ACBs to obtain a record of all updates to API discovery details for § 170.404(b)(2) and (3) on a quarterly basis each calendar year. This would ensure that ONC is aware of the latest API Discovery Details published on a quarterly basis by Certified API Developers meeting the requirements in § 170.404(b)(2) and (3) and would support ONC in hosting a link to developers' API discovery details on the Certified Health IT Product List (CHPL) or another website hosted by ONC. Our proposed requirement for § 170.523(m)(6) is consistent with similar existing requirements for adaptations and updates in § 170.523(m), which require ONC-ACBs to obtain records on a quarterly basis. Further, this same requirement is already in place for a related certification criterion, § 170.315(d)(13), which requires health IT developers to publish information and has a corresponding requirement for ONC-ACBs to obtain a record on a quarterly basis in § 170.523(m)(3).</P>
                    <HD SOURCE="HD3">4. New ONC-ACB Principle of Proper Conduct for Notice of Program Withdrawal</HD>
                    <P>To date, we have handled the infrequent occurrence of an ONC-ACB withdrawing from the Program by working collaboratively with that departing ONC-ACB and the other remaining ONC-ACBs to enable an orderly transition of certifications administered by the departing ONC-ACBs. However, as the Program has matured and the scope of an ONC-ACB's responsibilities has increased (including proposals in this proposed rule), a requirement for an ONC-ACB to provide notice to the National Coordinator when it intends to withdraw from the Program would further support an orderly transition. Accordingly, we propose in § 170.523(y) a new Principle of Proper Conduct for ONC-ACBs requiring an ONC-ACB to give the National Coordinator sufficient notice of its intent to withdraw its authorization under the Program. We believe that notice provided 180 days (day is defined in § 170.102 as a calendar day or calendar days) prior to the ONC-ACB's withdraw from the Program would be sufficient time for ONC to work with the ONC-ACB to ensure the ONC-ACB's planned withdrawal does not interrupt Program operations and activities, put its clients at risk of losing their certification(s) under the Program, and/or impact end users' ability to meet their business needs and requirements for participation in other Federal and/or state programs that require the use of certified health IT.</P>
                    <P>When an ONC-ACB withdraws its authorization from the Program, ONC must work with that ONC-ACB to ensure the ONC-ACB's clients are able to transition to another ONC-ACB and maintain their certified status. For an ONC-ACB to onboard a new client and issue a new certificate based on the evidence supporting a certificate previously issued by another ONC-ACB, it must possess the evidence that supports the prior ONC-ACB's decision. The transition requires the transfer of test records and other documented evidence supporting the certification. Consistent with § 170.523(g)(1), ONC-ACBs are required to retain all records related to the certificates they issue, and per § 170.523(g)(2) make such records available to HHS upon request during the specified retention period. Therefore, to maintain the integrity of the certifications impacted by the ONC-ACB withdrawal, ONC will request records (per § 170.523(g)(2)) from the withdrawing ONC-ACB. These records will provide evidence of conformity with certification requirements to support the remaining ONC-ACBs that take on the withdrawing ONC-ACB's clients. These steps are important because, once an ONC-ACB withdraws from the Program, ONC no longer has authority over the actions of that organization. Furthermore, the influx of incoming business for the ONC-ACBs accepting requests from the withdrawing ONC-ACB's clients must be managed along with their existing workload.</P>
                    <P>
                        Specifically, we propose to add two paragraphs in § 170.523(y). In § 170.523(y)(1), we propose to require the withdrawing ONC-ACB to provide ONC with notice of its intent to withdraw from the Program 180 days before its actual withdrawal. In § 170.523(y)(2), we propose to require the withdrawing ONC-ACB to submit all of its certification records to ONC pursuant to the retention requirements it followed in § 170.523(g). We believe the combination of these two proposals will give all parties involved (
                        <E T="03">i.e.,</E>
                         ONC, the withdrawing ONC-ACB, and remaining ONC-ACBs) sufficient time to manage transition activities with minimal interruption to Program activities.
                    </P>
                    <HD SOURCE="HD3">5. Updates to ONC Direct Review Procedures</HD>
                    <P>In the EOA Final Rule, we created a regulatory framework for ONC's “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 such health IT (81 FR 72404). The EOA Final Rule established bases on which ONC would initiate direct review, and procedures for ONC to follow in the event ONC's direct review of certified health IT substantiated a non-conformity. Under the framework established in the EOA Final Rule, inquiry into certified health IT's conformance with Program requirements may be conducted by ONC or a third party on ONC's behalf, and the term “direct review” is used to distinguish inquiries and enforcement actions taken under the 45 CFR 170.580 framework from ONC-ACBs' assessments and reviews as part of the ONC-ACB's surveillance and other responsibilities under the Program (85 FR 25738).</P>
                    <P>
                        In the ONC Cures Act Final Rule (85 FR 25642), we finalized use of substantially the same processes established in the EOA Final Rule (81 FR 72404) for the enforcement of the 
                        <PRTPAGE P="63612"/>
                        Conditions and Maintenance of Certification requirements for four stated reasons (85 FR 25783). First, these processes were designed to address non-conformities with Program requirements. Conditions and Maintenance of Certification requirements have been adopted as Program requirements and, as such, any noncompliance with the Conditions and Maintenance of Certification requirements constitutes a Program non-conformity. Second, health IT developers were already familiar with the ONC direct review framework that had been put in place by the EOA Final Rule. Third, 45 CFR 170.580 provides thorough and transparent processes for identifying, notifying, and addressing non-conformities in the Program through coordination with health IT developers to craft a CAP that will remedy Program non-conformities. Fourth, the updated direct review framework provides equitable opportunities for health IT developers to respond to ONC actions and appeal certain ONC determinations. We confirmed in the ONC Cures Act Final Rule that we would continue to use the term “direct review” to describe activities of ONC (or a third party on ONC's behalf) under the 45 CFR 170.580 framework and to differentiate them from ONC-ACBs' reviews of certified health IT under their surveillance responsibilities outlined in 45 CFR 170.556 (85 FR 25783).
                    </P>
                    <P>In this proposed rule, we propose to revise parts of the ONC direct review regulatory framework in 45 CFR 170.580, including:</P>
                    <P>• 45 CFR 170.580(b) and (c) requirements for timeliness and content of health IT developers' CAPs in response to a notice that ONC has confirmed a non-conformity with Program requirements (discussed below in section III.D.3.a);</P>
                    <P>• 45 CFR 170.580(d) and (f) provisions for suspension and termination of certification for failure of certified health IT products or a Program-participating health IT developer to meet Program requirements (discussed below in section III.D.5.b); and</P>
                    <P>• 45 CFR 170.580(g) opportunity and procedures for heath IT developer appeals of ONC enforcement actions under § 170.580(d) or (f) and § 170.581 (discussed below in section III.D.5.b of this proposed rule).</P>
                    <HD SOURCE="HD3">a. Health IT Developers' Response to Notices of Non-conformity and Corrective Action Plan Requirements</HD>
                    <P>We propose to revise regulatory provisions specific to the timing and content of health IT developers' responses to notices of non-conformity, as well as the mandatory minimum content of developers' CAPs, to improve efficiency for both ONC and developers under direct review.</P>
                    <P>
                        We propose to revise paragraph § 170.580(b)(2)(ii)(A)(
                        <E T="03">3</E>
                        ) to require that, where multiple responses are provided pursuant to this paragraph, information provided in earlier responses be labeled as previously submitted. The intent of this proposed revision is to increase efficiency for ONC by making it clear that repeated submission of the same information in response to the same Notice of Non-Conformity should generally be avoided.
                    </P>
                    <P>We propose to leave in place the flexibility that health IT developers currently have to re-submit the same information in multiple communications in response to any particular Notice of Non-Conformity. Because the information that a developer may need to provide in response to a Notice of Non-Conformity can include detailed technical or business practices data, we propose to balance this developer flexibility with a requirement that if a developer does elect to resubmit the same data or information, that it must label such data or information as having been previously submitted in response to the same Notice of Non-Conformity. The labeling of any resubmitted materials would promote efficiency by enabling ONC reviewers to immediately focus on updates, addenda, or refreshed discussion of the resubmitted data.</P>
                    <P>
                        As discussed in section III.D.2.c above, we now have some experience evaluating non-conformities associated with developers failing to comply with administrative Maintenance of Certification requirements in 45 CFR 170 subpart D. We have learned from this experience that some of the mandatory minimum elements that § 170.580(c)(2) currently requires for all CAPs are not equally valuable with respect to all non-conformities. For example, an assessment and description of the nature, severity, and extent of the non-conformity (the element specified in § 170.580(c)(2)(i)) would likely be necessary where the ONC-substantiated non-conformity is that a certified Health IT Module is causing or contributing to a serious risk to public health or safety. The § 170.580(c)(2)(i) element would also likely be necessary in cases where a certified Health IT Module is found to be non-conforming by virtue of failing to satisfy the requirements of all 45 CFR 170 subpart C certification criteria to which it is certified. By contrast, the § 170.580(c)(2)(i) element is not likely to be necessary in many instances where the non-conformity is a failure to meet an administrative requirement under subpart D, such as to timely submit real world testing documentation pursuant to § 170.405(b), or to submit required attestations pursuant to § 170.406. Timely submission of attestations is a pass/fail, readily observed non-conformity for which inclusion of the § 170.580(c)(2)(i) element would not provide helpful or additional information. Similarly, where the resolution of the non-conformity amounts to submitting the overdue attestations or real world testing documentation, the successful resolution is self-documenting, so a detailed description of supporting documentation a developer would provide 
                        <E T="03">to demonstrate</E>
                         the identified non-conformity is resolved (as specified in § 170.580(c)(2)(vi), emphasis added) generally would not be necessary or add value to the direct review process.
                    </P>
                    <P>We propose to revise paragraph (c)(2) of § 170.580 to establish flexibility for ONC to identify, for any particular non-conformity, the subset of the elements listed in subparagraphs (i) through (viii) relevant to demonstrating the resolution to each non-conformity. We propose the National Coordinator may explicitly waive any of the subset of elements listed in subparagraphs (i) through (viii). ONC would continue to provide direction to the health IT developer as to the required elements of the CAP for each identified non-conformity.</P>
                    <HD SOURCE="HD3">b. Suspension, Termination, and Appeals</HD>
                    <P>We propose modifications to our suspension, termination, and appeals regulations for several reasons. Some proposed revisions would simply ensure clarity as to who makes, and where ultimate accountability lies with respect to, certain decisions. Other proposed revisions would update procedures to reflect other Program changes proposed elsewhere in this rule or update regulatory text to remove now-obsolete terminology.</P>
                    <HD SOURCE="HD3">Suspension, Termination, and Appeals Decisions</HD>
                    <P>
                        We propose to clarify in our regulatory text that our procedures for decisions to terminate the certification of Health IT Modules or issue certification bans under § 170.581 are made by the National Coordinator, whom the Secretary appoints to head ONC pursuant to 42. U.S.C. 300jj-11. We also propose to revise § 170.580 and § 170.581 to explicitly provide for the Secretary to have an opportunity to exercise direct oversight of these 
                        <PRTPAGE P="63613"/>
                        determinations as well as for hearing officer determinations under 45 CFR 170.580(g). Specifically, we propose to revise paragraphs (d), (f), and (g) of § 170.580 (and to revise § 170.581, as discussed in section III.D below).
                    </P>
                    <P>We propose to modify § 170.580(d) and § 170.580(f) to reflect that the National Coordinator makes determinations to suspend or terminate a certification, and to cancel a suspension or to rescind a termination determination. But, to ensure that it is clear, notwithstanding the decision of the National Coordinator, that the Secretary, a principal officer of the United States, retains ultimate responsibility for such decision-making, we propose that the Secretary may, at the Secretary's discretion, review a determination of the National Coordinator. The Secretary may direct the National Coordinator to cancel a suspension (paragraph (d)(6)(ii)) or review a termination determination made by the National Coordinator before such suspension or the termination would become effective (paragraph (f)(5)). We propose in § 170.580(f)(5) that, should the Secretary direct the National Coordinator to rescind a termination, ONC may resume (§ 170.580(f)(5)(i)) or end (§ 170.580(f)(5)(ii)) all or part of its review of certified health IT or a health IT developer's actions or practices under this section unless the Secretary specifically directs otherwise.</P>
                    <HD SOURCE="HD3">Updates to Align with Other Proposals in This Proposed Rule</HD>
                    <P>We propose to modify paragraph (f) of § 170.580 to align with proposed added responsibilities of ONC-ACBs for confirming and encouraging compliance with certain Maintenance of Certification requirements codified in subpart D of 45 CFR part 170 (discussed in section III.D.2 of this proposed rule, above). Specifically, we propose in § 170.580(f)(1)(iv) to provide for the National Coordinator to terminate a certification based on ONC review of the information and documentation reported by the ONC-ACB pursuant to the principles of proper conduct (PoPC) proposed in paragraph (x) of § 170.523 (discussed in section III.D.2.b) that the developer did not fulfill its obligation under a CAP. This would explicitly establish that the National Coordinator may make a termination determination without ONC being required to engage in duplicative fact-finding in applicable non-conformity cases. Applicable cases would be those where the information and documentation provided in the ONC-ACB's § 170.523(x) report is, in the National Coordinator's view, sufficient to substantiate that a developer has failed to resolve a Program non-conformity related to a Maintenance of Certification requirement within the required timeframe of the CAP verified and approved by the ONC-ACB. The National Coordinator's consideration of the record submitted by the ONC-ACB pursuant to § 170.523(x) would include assessing whether the ONC-ACB had met its obligations to notify the developer of the non-conformity and initiate corrective action procedures under §§ 170.523 and 170.556.</P>
                    <P>
                        We also propose revisions to § 170.580(a)(3)(iii), (a)(3)(v), and (a)(4)(ii) to clarify that the: (1) National Coordinator's determination on matters under ONC direct review is controlling and supersedes any determination by an ONC-ACB; (2) National Coordinator may end all or any part of ONC's review of certified health IT or a health IT developer's actions at any time; and (3) National Coordinator may rely on HHS Office of Inspector General (OIG) findings to form the basis of a direct review action. We also propose revisions to § 170.580(b)(2)(ii)(B) and § 170.580(b)(2)(iii) clarifying that the National Coordinator may adjust the 30-day timeline under § 170.580(b)(2)(ii)(A)(
                        <E T="03">3</E>
                        ) and that the National Coordinator makes a determination under § 170.580(b)(2)(iii) after receiving the health IT developer's written explanation and supporting documentation. We propose to revise § 170.580(c)(1) clarifying that if the National Coordinator determines that certified health IT or a health IT developer's action or practice does not conform to requirements of the Program, ONC will notify the health IT developer of its determination and require the health IT developer to submit a proposed CAP. In § 170.580(c)(2), we propose that the CAP shall include such required elements that the National Coordinator determines necessary. The CAP shall include, for each specific non-conformity, all the elements in § 170.580(c)(2) except when the elements are explicitly waived by the National Coordinator. We also propose to update § 170.580(c)(7) to provide that a CAP may be reinstituted by ONC if the National Coordinator later determines that a health IT developer has not yet fulfilled all its obligations under the CAP.
                    </P>
                    <P>We also propose revisions to § 170.580(e)(1), (e)(1)(vii), (e)(2), and (e)(4) clarifying the actions that the National Coordinator can take with a proposed termination and updating the existing language to clarify that certain decisions are made by the National Coordinator, with ultimate accountability for the National Coordinator's decisions vested in the Secretary as discussed above. More specifically, we propose that: (1) excluding situations of noncompliance with a Condition or Maintenance of Certification requirement under subpart D of this part, the National Coordinator may propose to terminate a certification issued to a Health IT Module when a health IT developer fails to respond timely to a communication from ONC, fails to provide sufficient access or information to ONC, or the National Coordinator concludes that a certified health IT's non-conformity(ies) cannot be cured (§ 170.580(e)(1) and (e)(1)(vii)); (2) ONC will notify the health IT developer of the proposed termination through a notice of proposed termination when the National Coordinator decides to propose to terminate a certification (§ 170.580(e)(2)); and, (3) upon receipt of the health IT 'developer's written response to a notice of proposed termination, the National Coordinator has up to 30 days to make a determination based on ONC's review of the information submitted by the health IT developer and the National Coordinator may extend this timeframe if the complexity of the case requires additional time for ONC review (§ 170.580(4)).</P>
                    <HD SOURCE="HD3">c. Appeals</HD>
                    <P>The ONC direct review regulatory framework established in the EOA Final Rule (81 FR 72404) included (in § 170.580(g)) procedural provisions for developers to appeal certification termination determinations made by the National Coordinator under § 170.580(f) as well as Program bans issued under § 170.581. In the ONC Cures Act Final Rule, we established that we would use the processes previously put in place for ONC direct review of certified health IT in the enforcement of the Conditions and Maintenance of Certification requirements. In doing so, we finalized modifications to § 170.580(g) provisions to address the inclusion of Condition and Maintenance of Certification requirements under § 170.580(f) and § 170.581 (85 FR 25649 and 25787).</P>
                    <P>
                        We propose to rename § 170.580(g)(5) to “Assignment of a hearing officer” and clarify the text to explain that the National Coordinator will arrange for assignment of the case to a hearing officer to adjudicate the appeal on the National Coordinator's behalf, and add subparagraph (iii) that the hearing officer must be an officer properly appointed by the Secretary of Health and Human Services.
                        <PRTPAGE P="63614"/>
                    </P>
                    <P>We propose to explicitly provide in § 170.580(g)(7)(ii) for the Secretary, at the Secretary's discretion, to review and revise or rescind hearing officer decisions before these decisions become the final decision of HHS. This proposed change would ensure the regulatory text is explicit that the Secretary, as a principal officer of the United States, holds appropriate oversight and accountability for the hearing officer's decisions.</P>
                    <P>We welcome comments on these proposals.</P>
                    <HD SOURCE="HD3">6. Certification Ban</HD>
                    <P>We propose to update paragraphs (a) and (b) of the certification ban provisions in § 170.581 to explicitly provide for the Secretary to review, at the Secretary's discretion, the National Coordinator's determination to impose a ban before the ban becomes effective. We further propose updates to § 170.581(a)(2) and (d)(4) to indicate that the National Coordinator as a duly appointed officer of the United States, rather than ONC as an organization, would make any determination to impose a certification ban on a developer. These proposed revisions are similar to those we discussed above for suspension and termination.</P>
                    <P>We propose to update the wording of § 170.581(a)(1)(i) to replace a reference to termination of a Health IT Module “under the ONC Health IT Certification Program” to cross-reference the paragraph within § 170.580 specific to termination of a certification in the context of ONC direct review. We believe the specific cross-reference would make it easier for developers, ONC-ACBs, and other interested parties to read and understand § 170.581(a)(1)(i).</P>
                    <P>In parallel to our proposed addition of PoPCs and surveillance responsibilities for ONC-ACBs specific to certain Maintenance of Certification requirements in subpart D of 45 CFR part 170 (both in § 170.523), we propose to explicitly establish in § 170.581(a)(2) that the National Coordinator would have the option of determining a certification ban is appropriate based on the information and documentation provided in an ONC-ACB's § 170.523(x) report. We believe this is important to ensure that the National Coordinator can take prompt action, without duplicative data gathering or fact finding, where the information and record submitted by the ONC-ACB indicates to the National Coordinator that a program ban is appropriate.</P>
                    <P>We welcome comment on these proposals.</P>
                    <HD SOURCE="HD3">7. Updates Pursuant to 2014 Edition Removal</HD>
                    <P>We propose to remove the “Complete EHR” and “EHR Module” terms from certain sections within subpart E of 45 CFR 170. By the time we would finalize any proposal in this proposed rule, the terms would no longer be relevant, as described below, due to the amount of time that will have elapsed since the June 30, 2020, effective date of the ONC Cures Act Final Rule's removal of the 2014 Edition from subparts A, B, and C of part 170. We believe removing obsolete terms as the Program evolves over time maintains clarity of the regulatory text and Program provisions, particularly for regulated entities and interested parties.</P>
                    <HD SOURCE="HD3">a. Removal of “Complete EHR” References</HD>
                    <P>The ONC Cures Act Final Rule removed the 2014 Edition certification criteria in § 170.314 from the Program regulations in 45 CFR part 170 (85 FR 25656). The rule also finalized our proposals (84 FR 7434 through 7435) to remove terms and definitions specific to the 2014 Edition from § 170.102, including the “2014 Edition Base EHR,” “2014 Edition EHR certification criteria,” and “Complete EHR, 2014 Edition” definitions. As explained in the 2015 Edition Final Rule (80 FR 62719), the “Complete EHR” concept was discontinued for the 2015 Edition. In conjunction with the removal of the 2014 Edition, we also removed references to “Complete EHR” from § 170.545 and removed the standards and implementation specifications found in §§ 170.200, 170.202, 170.204, 170.205, 170.207, 170.210, and 170.299 that were referenced only in the 2014 Edition certification criteria (85 FR 25656). In the HTI-1 Final Rule, we removed the “Complete EHR” language from all reference points in §§ 170.523 and 170.524 (89 FR 1209 through 1210).</P>
                    <P>Although we removed terms, standards, and certification criteria that were applicable only to the 2014 Edition in the ONC Cures Act Final Rule, we have retained until now reference to “Complete EHRs” in certain provisions within subpart E of 45 CFR part 170:</P>
                    <P>• The definition of “gap certification” (§ 170.502);</P>
                    <P>• Authorization scope for ONC-ATL status (§ 170.511);</P>
                    <P>• Requirements for ONC-ACBs to refund fees to developers seeking certification under certain circumstances (§ 170.523(j)(3)); and</P>
                    <P>• Applicability of a newer version of a minimum standard (§ 170.555(b)(2)).</P>
                    <P>Retaining reference to “Complete EHRs” in these part 170 subpart E requirements has supported continuity following the removal of the 2014 Edition's standards and certification criteria from 45 CFR part 170. For example, in the update of ONC-ACB record retention requirements in §§ 170.523 and 170.524 to align with the transition of the Program's structure and terminology away from annual themed “editions,” the “Complete EHR” concept remained relevant to these provisions at that time because the 2014 Edition was not removed from the CFR until the ONC Cures Act Final Rule (85 FR 25655). The ONC Cures Act Final Rule became effective on June 30, 2020, and records for the 2014 Edition were required to be retained (including Complete EHRs) until June 30, 2023, under 45 CFR 170.523(g)(1).</P>
                    <P>Beginning with the 2015 Edition, Complete EHR certifications could no longer be issued and December 31, 2023, has passed. Thus, we now propose to remove references to “Complete EHRs” from §§ 170.502,170.511, 170.523(j)(3), and 170.555(b)(2) as of the effective date of a subsequent final rule for this rulemaking.</P>
                    <HD SOURCE="HD3">b. Removal of “EHR Modules” References</HD>
                    <P>In the 2011 “Establishment of the Permanent Certification Program for Health Information Technology” Final Rule (76 FR 1261), we used the Complete EHR and EHR Module terms and phrasing “Complete EHRs and/or EHR Modules.” In the rule, we stated our initial focus would be on EHR technology and supporting the EHR Incentive Programs, which at the time, focused on the ambulatory and inpatient settings (76 FR 1294).</P>
                    <P>As we explained in the 2015 Edition Final Rule (80 FR 62601), we changed the name of the ONC HIT Certification Program to the “ONC Health IT Certification Program” (Program). We also modified the Program in ways that 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 (80 FR 62604). These modifications also served to support other public and private programs that may reference the use of health IT certified under the Program (80 FR 62604).</P>
                    <P>
                        Consistent with the three-year records retention requirement for ONC-ACBs (45 CFR 170.523(g)(1), June 30, 2023, marked the end of a three-year minimum retention period (36 calendar months) since we finalized, in the ONC Cures Act Final Rule, the removal of the 2014 Edition from 45 CFR subparts A, 
                        <PRTPAGE P="63615"/>
                        B, and C (85 FR 25656). Similarly, December 31, 2023, marked the end of the third calendar year following the calendar year in which the ONC Cures Act Final Rule became effective. Because we have now passed both rules' three-year retention requirements for ONC-ACBs and the term “EHR Module” is no longer relevant, we propose to remove from § 170.523(f) reference to “EHR Modules.”
                    </P>
                    <HD SOURCE="HD3">8. Definition of Serious Risk to Public Health or Safety</HD>
                    <P>
                        We propose to revise 45 CFR 170.102 to include a definition of 
                        <E T="03">serious risk to public health or safety.</E>
                         The purpose of this proposed definition is to enhance understanding among developers and users of certified health IT of the types of conditions, events, or phenomena that would constitute egregiously dangerous non-conformities with Program requirements. Such events could be caused or contributed to by health IT certified as a Health IT Module or as part of a certified Health IT Module even if the certified Health IT Module(s) continued to pass lab testing procedures, in-the-field surveillance testing, or both with respect to the technical standards and certification criteria adopted in subparts B and C of part 170. Within the proposed regulation text for this proposed definition of serious risk to public health or safety, we have included fact patterns in (1) through (6) that would always meet the definition of 
                        <E T="03">serious risk to public health or safety.</E>
                         For purposes of these examples, a “user” of a certified Health IT Module would be any human being or any software application, process, or service that is authorized, intended, and enabled to create, read, update, or delete (CRUD) or to command the certified Health IT Module to execute specific CRUD functions on specific data entries. We request public comment on this definition, including but not limited to the illustrative examples.
                    </P>
                    <P>
                        We would continue to expect, as we reiterated in the EOA Final Rule, that ONC direct review on the bases of risk to public safety or where ONC-ACBs may be unable to respond effectively would occur relatively infrequently (
                        <E T="03">cf., e.g.,</E>
                         81 FR 72404 at 72415 or 74216). As we explained in the EOA Final Rule, we do not believe every risk to public health or safety necessitates ONC's direct review. We also recognize the need to prioritize ONC's limited resources by focusing on the kinds of problems and other issues that, if not addressed through ONC's direct review, are most likely to lead to harm to patients or the public and undermine confidence in health IT and the integrity of the Program (81 FR 72419). This proposed definition would not change this need to prioritize ONC's resources.
                    </P>
                    <HD SOURCE="HD3">9. Removal of Time-Limited Criteria</HD>
                    <P>In the ONC Cures Act Final Rule, we finalized § 170.550(m) “time-limited certification and certification status for certain 2015 Edition certification criteria” which provided that for five specific certification criteria, an ONC-ACB may only issue a certification to a Health IT Module and permit continued certified status for a specified time period (85 FR 25952). The five criteria with time-limited certification and certification status are found in § 170.315(a)(10), (a)(13), (b)(6), (e)(2), and (g)(8). Because the specified time periods for certification to these criteria have elapsed, we propose to remove all of the certification criteria referenced in § 170.550(m) in one action by removing and reserving § 170.550(m) in its entirety. We also propose to remove and reserve these aforementioned certification criteria from the specific CFR locations in which they are adopted. In the ONC Cures Act Final Rule, we also finalized revisions in § 170.315(b)(7)(ii) and (b)(8)(i)(B) to allow security tagging of Consolidated-Clinical Document Architecture (C-CDA) documents at the document level only for the period until 24 months after publication date of the final rule (85 FR 25667). Because that time period has elapsed, we propose to revise § 170.315(b)(7) and (8) to remove § 170.315(b)(7)(ii) and (b)(8)(i)(B). We describe our detailed proposals below.</P>
                    <P>The requirements finalized in the ONC Cures Act Final Rule in § 170.550(m)(1) permit ONC-ACBs to issue certificates for the “drug-formulary and preferred drug list checks” certification criterion in § 170.315(a)(10) up until January 1, 2022 (85 FR 25661). We stated in the ONC Cures Act Final Rule that we believed the functionality in § 170.315(a)(10) was ubiquitous due to widespread adoption of health IT certified to the 2014 Edition and that we did not believe it was necessary to continue to require certification to it under the Program in order to ensure it remains widely available (85 FR 25661). We also stated that because the certification criterion did not require use of standards or directly drive interoperability, we did not believe its continued inclusion in the Program would provide sufficient value to providers or patients to justify the burden on developers and providers (85 FR 25661). We propose to remove and reserve § 170.315(a)(10).</P>
                    <P>In the ONC Cures Act Final Rule, we finalized requirements in § 170.550(m)(1) permitting ONC-ACBs to issue certificates for the “patient-specific education resources” certification criterion in § 170.315(a)(13) up until January 1, 2022 (85 FR 25661). We stated that we believed that health IT's capabilities to identify appropriate patient education materials was widespread among health IT developers and their customers, and noted innovation had occurred for these capabilities, including the use of automation and algorithms to provide appropriate education materials to patients in a timely manner (85 FR 25661). We also stated that we believed this certification criterion was no longer the best way to encourage innovation and advancement in the capabilities of health IT to support clinician-patient interactions and relationships (85 FR 25661). We propose to remove and reserve § 170.315(a)(13).</P>
                    <P>The requirements finalized in the ONC Cures Act Final Rule in § 170.550(m)(1) permitted ONC-ACBs to issue certificates for the “secure messaging” certification criterion in § 170.315(e)(2) up until January 1, 2022 (85 FR 25662). In the ONC Cures Act Final Rule, while we did not finalize removal of the requirements in § 170.315(e)(2), we stated that we no longer believed that a separate certification criterion focused on a health IT's capabilities to send and receive secure messages between health care providers and patients was necessary and that the certification criterion would also no longer be associated with an objective or measure under the CMS PI Programs (85 FR 25662). We propose to remove and reserve § 170.315(e)(2).</P>
                    <P>
                        In the ONC Cures Act Final Rule, we finalized requirements in § 170.550(m)(2) permitting ONC-ACBs to issue certificates for the “data export” certification criterion in § 170.315(b)(6) up until May 1, 2023 (85 FR 25662). This date was later extended to December 31, 2023, in the Information Blocking and the ONC Health IT Certification Program: Extension of Compliance Dates and Timeframes in Response to the COVID-19 Public Health Emergency Interim Final Rule (85 FR 70070). We noted in the ONC Cures Act Final Rule that § 170.315(b)(6) was replaced by the “EHI export” certification criterion in § 170.315(b)(10) and removed from the 2015 Edition Base EHR definition in § 170.102, and that this would encourage movement toward the interoperability opportunities afforded by new criteria 
                        <PRTPAGE P="63616"/>
                        (85 FR 25699). We propose to remove and reserve § 170.315(b)(6).
                    </P>
                    <P>The requirements finalized in the ONC Cures Act Final Rule in § 170.550(m)(2) permit ONC-ACBs to issue certificates for the certification criterion in § 170.315(g)(8) “application access—data category request” up until May 2, 2022 (85 FR 25666). This date was later extended to December 31, 2022, in the Information Blocking and the ONC Health IT Certification Program: Extension of Compliance Dates and Timeframes in Response to the COVID-19 Public Health Emergency Interim Final Rule (85 FR 70070). We noted in the ONC Cures Act Final Rule that we had adopted a new API certification criterion in § 170.315(g)(10) to replace the certification criterion in § 170.315(g)(8) and added the new certification criterion to the updated 2015 Edition Base EHR definition (85 FR 25645). We propose to remove and reserve § 170.315(g)(8).</P>
                    <P>In the ONC Cures Act Final Rule, we finalized revisions in § 170.315(b)(7)(ii) and (b)(8)(i)(B) to allow certification of health IT to demonstrate security tagging of Consolidated-Clinical Document Architecture (C-CDA) documents at the document level only for the period until 24 months after publication date of the final rule (85 FR 25707). This date was later extended to December 31, 2022, in the Information Blocking and the ONC Health IT Certification Program: Extension of Compliance Dates and Timeframes in Response to the COVID-19 Public Health Emergency Interim Final Rule (85 FR 70070). We noted in the ONC Cures Act Final Rule that only requiring tagging C-CDA documents at the document level did not permit providers the flexibility to address more complex use cases for representing patient privacy preferences (85 FR 25645). We now propose to revise § 170.315(b)(7) and (b)(8) to remove § 170.315(b)(7)(ii) and (b)(8)(i)(B).</P>
                    <HD SOURCE="HD3">10. Privacy and Security Framework Incorporation of DSI Criterion</HD>
                    <P>In the ONC HTI-1 Final Rule, we established a revised certification criterion (“decision support interventions” (§ 170.315(b)(11)) to replace the “clinical decision support” certification criterion (§ 170.315(a)(9)) effective January 1, 2025 (89 FR 1196 through 1197). When finalizing the “decision support interventions” certification criterion, we did so by adopting a substantially similar structure to the structure of the “clinical decision support” certification criterion. However, we neither proposed nor finalized corresponding privacy and security certification requirements for Health IT Modules certifying to the “decision support interventions” certification criterion. This omission was an oversight. We now propose to add the “decision support interventions” certification criterion (§ 170.315(b)(11)) to the list of certification criteria in § 170.550(h)(3)(ii). This proposal would ensure that the same privacy and security certification requirements that apply to the “clinical decision support” certification criterion (§ 170.315(a)(9)) also apply to Health IT Modules certified to the “decision support interventions” certification criterion.</P>
                    <P>To provide developers of certified health IT time to comply with these proposed requirements, we specifically propose to require, in § 170.550(h)(3)(ii), that Health IT Modules certified to the “decision support interventions” (§ 170.315(b)(11)) must also be certified to the specific privacy and security certification criteria on and after January 1, 2028. These specific privacy and security certification criteria are: “authentication, access control, and authorization” in § 170.315(d)(1); “auditable events and tamper-resistance” in § 170.315(d)(2); “audit report(s)” in § 170.315(d)(3); “automatic access time-out” in § 170.315(d)(5); “end-user device encryption” in § 170.315(d)(7); “encrypt authentication credentials” in § 170.315(d)(12); and “multi-factor authentication” in § 170.315(d)(13).</P>
                    <P>We note that should we finalize our proposed revisions to “encrypt authentication credentials” in § 170.315(d)(12) (as discussed in section III.B.12) and finalize our proposal to revise § 170.550(h)(3)(ii) as described above, those revised requirements would apply to Health IT Modules certified to the “decision support interventions” certification criterion (§ 170.315(b)(11)). However, we further note that should we finalize our proposed revisions to the “multi-factor authentication” certification criterion in § 170.315(d)(13) as described in section III.B.17, and should we finalize our proposal to revise § 170.550(h)(3)(ii) as described above, Health IT Modules certified to the “decision support interventions” certification criterion would not be required to support the new multi-factor authentication requirements, due to the timing included in our proposed updates in § 170.550(h)(3)(ii), unless those Health IT Modules are also certified to § 170.315(b)(3), § 170.315(e)(1), § 170.315(g)(10), or § 170.315(g)(30) and required to meet the multi-factor authentication requirements in those certification criteria in § 170.315(b)(3)(ii)(G), § 170.315(e)(1)(iii), § 170.315(g)(10)(ii)(A)(1)(iii), or § 170.315(g)(30)(ii)(c) respectively.</P>
                    <HD SOURCE="HD2">E. Correction—Privacy and Security Certification Framework</HD>
                    <P>
                        We propose to make a correction to the Privacy and Security Certification Framework in § 170.550(h). We revised § 170.550(h) in the ONC Cures Act Final Rule but intended for § 170.550(h)(4) to remain unchanged. However, when we drafted the amendatory instructions, we erroneously included the instruction to revise all of paragraph (h) (85 FR 25952). Therefore, when the Code of Federal Regulations (CFR) was updated, § 170.550(h)(4) was removed. We now propose to add back to the CFR 170.550(h)(4) [45 CFR 170.550(h)(4) (Jan. 1, 2020)] as it existed prior to the ONC Cures Act Final Rule. The language in § 170.550(h) to be added to paragraph (4) is, “
                        <E T="03">Methods to demonstrate compliance with each privacy and security criterion.</E>
                         One of the following methods must be used to meet each applicable privacy and security certification criterion listed in paragraph (h)(3) of this section: (i) Directly, by demonstrating a technical capability to satisfy the applicable certification criterion or certification criteria; or (ii) Demonstrate, through system documentation sufficiently detailed to enable integration, that the Health IT Module has implemented service interfaces for each applicable privacy and security certification criterion that enable the Health IT Module to access external services necessary to meet the privacy and security certification criterion.
                    </P>
                    <HD SOURCE="HD1">IV. Information Blocking Enhancements</HD>
                    <HD SOURCE="HD2">A. Defined Terms</HD>
                    <HD SOURCE="HD3">1. Health Care Provider</HD>
                    <P>
                        Health care provider, as defined in 45 CFR 171.102 for purposes of the information blocking regulations, has the same meaning as `health care provider' in 42 U.S.C. 300jj. As finalized in the ONC Cures Act Final Rule (85 FR 25642), this definition cites to the entirety of 42 U.S.C. 300jj (section 3000 of the Public Health Service Act (PHSA)). We now propose to provide additional regulatory clarity for the “health care provider” definition and for certain types of health care providers referenced by the “health care provider” definition. We propose to revise § 171.102 to explicitly reference the “health care provider” definition in 42 U.S.C. 300jj(3) and the definitions of 
                        <PRTPAGE P="63617"/>
                        “laboratory” in 42 U.S.C. 300jj(10) and “pharmacist” in 42 U.S.C. 300jj(12).
                    </P>
                    <P>In the ONC Cures Act Final Rule (85 FR 25794), we adopted a definition of “health care provider” citing 42 U.S.C. 300jj, indicating we had noted in the ONC Cures Act Proposed Rule (84 FR 7510) that the PHSA section 3000(3) definition is different from the definition of “health care provider” in 45 CFR 160.103 for purposes of the HIPAA Privacy and Security Rules. We now propose to revise the definition of “health care provider” in § 171.102 to explicitly cite 42 U.S.C. 300jj(3).</P>
                    <P>In addition, we propose to explicitly incorporate the PHSA section 3000 definitions of “laboratory” and “pharmacist.” The “health care provider” definition in paragraph (3) of PHSA section 3000 (cited in the regulatory text as 42 U.S.C. 300jj(3)) references these types of health care providers without further definition. While our interpretation of these types of health care providers has always relied on the 42 U.S.C. 300jj(10) and (12) definitions of “laboratory” and “pharmacist,” we now propose to formally incorporate these definitions into the health care provider definition codified in § 171.102. Specifically, we propose to add to the § 171.102 definition of “health care provider” subparagraphs designated as (1) and (2) and citing, respectively, paragraphs (10) and (12) of 42 U.S.C. 300jj. In 42 U.S.C. 300jj(10), “laboratory” has the meaning given such term in 42 U.S.C. 263a(a) (PHSA section 353(a)). In 42 U.S.C. 300jj(12), “pharmacist” has the meaning given such term in 21 U.S.C 384(a)(2). For ease of reference, we provide in the following paragraphs of this preamble the laboratory and pharmacist definitions cross-referenced by 42 U.S.C. 300jj(10) and (12).</P>
                    <P>
                        As stated in 42 U.S.C. 263a(a): “laboratory” or “clinical laboratory” means “a facility for the biological, microbiological, serological, chemical, immuno-hematological, hematological, biophysical, cytological, pathological, or other examination of materials derived from the human body for the purpose of providing information for the diagnosis, prevention, or treatment of any disease or impairment of, or the assessment of the health of, human beings.” In addition to having been cited by 42 U.S.C. 300jj since the HITECH Act added Title XXX to the PHSA in 2009, this definition of “laboratory” or “clinical laboratory” has stood since the Clinical Laboratory Improvement Amendments of 1988 amended section 353 of the PHSA (42 U.S.C. 263a(a)) to include this definition.
                        <SU>227</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>227</SU>
                             
                            <E T="03">See</E>
                             section 2 of the Clinical Laboratory Improvement Amendments of 1988 (Pub. L. 100-578,102 Stat. 2903). 
                            <E T="03">See also</E>
                             42 U.S.C. 263a(a) authority citations (available online at 
                            <E T="03">https://uscode.house.gov/view.xhtml?req=granuleid:U.S.C.-prelim-title42-section263a&amp;num=0&amp;edition=prelim</E>
                            ).
                        </P>
                    </FTNT>
                    <P>
                        As stated in 21 U.S.C. 384(a)(2), the term “pharmacist” means “a person licensed by a State to practice pharmacy, including the dispensing and selling of prescription drugs.” While the text of 42 U.S.C. 300jj(12) cites “the meaning given such term in section 384(2) of title 21” the only definition of “pharmacist” appearing in 21 U.S.C. 384 is found in paragraph (a)(2).
                        <SU>228</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>228</SU>
                             Note 3 to 42 U.S.C. 300jj as it appears in the U.S. Code as maintained by the Office of law Revision Counsel of the U.S. House of Representatives reads: So in original. Probably should be “(a)(2)”. (Available online at: 
                            <E T="03">https://uscode.house.gov/view.xhtml?req=granuleid%3AUSC-prelim-title42-chapter6A-subchapter28&amp;saved=%7CZ3JhbnVsZWlkOlVTQy1wcmVsaW0tdGl0bGU0Mi1zZWN0aW9uMzAwamotNTI%3D%7C%7C%7C0%7Cfalse%7Cprelim&amp;edition=prelim#300jj_3_target.</E>
                            )
                        </P>
                    </FTNT>
                    <P>We welcome comment on this proposal.</P>
                    <HD SOURCE="HD3">2. Health Information Technology or Health IT</HD>
                    <P>We propose to codify in § 171.102 that, for purposes of the information blocking regulations in 45 CFR part 171, both “health information technology” and its shorter form, “health IT,” have the same meaning as “health information technology” in 42 U.S.C. 300jj(5). The health information technology definition was added to the Public Health Service Act (PHSA) (section 3000(5)) by the HITECH Act (see Title XIII, Subtitle A, section 13101 of the American Recovery and Reinvestment Act of 2009, Pub. L. 111-5). The PHSA defines health information technology as “hardware, software, integrated technologies or related licenses, intellectual property, upgrades, or packaged solutions sold as services that are designed for or support the use by health care entities or patients for the electronic creation, maintenance, access, or exchange of health information.”</P>
                    <P>
                        Because the 21st Century Cures Act added the information blocking statute to Title XXX of the PHSA as section 3022 (42 U.S.C. 300jj-52), we believe the most applicable definition of the term “health information technology” in the context of PHSA section 3022 and our regulations in 45 CFR part 171 is the definition found at 42 U.S.C. 300jj(5). We believe that codifying this interpretation will increase certainty for actors 
                        <SU>229</SU>
                        <FTREF/>
                         and other interested parties that when we refer to “health information technology” or “health IT” in 45 CFR part 171, we mean the 42 U.S.C. 300jj(5) definition unless otherwise specified in or for a specific subpart or section.
                    </P>
                    <FTNT>
                        <P>
                            <SU>229</SU>
                             Throughout Section IV of this proposed rule, we use “actor” as it is defined in § 171.102. (We do not propose in this rule to revise that codified definition.)
                        </P>
                    </FTNT>
                    <P>We leveraged the definition of “health information technology” from Title XXX of the PHSA (specifically, section 3000(5) of the PHSA) in finalizing the definition of “interoperability element” in § 171.102, but we did not use it in its entirety and did not explicitly cite it, in the “interoperability element” definition (85 FR 25956, see also preamble discussion at 85 FR 25807). This proposal to adopt a definition for “health information technology” in § 171.102 would not change the definition of “interoperability element” in § 171.102. Our definitions of “health IT developer of certified health IT” and “offer health IT” as they are currently codified in § 171.102 explicitly reference the definition of “health information technology” in 42 U.S.C. 300jj(5). Thus, this proposal would not change the meaning of either of those definitions.</P>
                    <P>We welcome comments on this proposal.</P>
                    <HD SOURCE="HD3">3. “Interfere With” or “Interference”</HD>
                    <P>
                        The 21st Century Cures Act defined information blocking in part as a practice that “is likely to interfere with, prevent, or materially discourage access, exchange, or use of electronic health information” (42 U.S.C. 300jj-52(a)(1)). In the definitions section of the information blocking regulations (§ 171.102), we define 
                        <E T="03">interfere with</E>
                         or 
                        <E T="03">interference</E>
                         to mean “to prevent, materially discourage, or otherwise inhibit.” We propose to add a new section (45 CFR 171.104) to codify certain practices that constitute “interference” and “interfere with” (as defined in § 171.102) for purposes of the information blocking definition in § 171.103. Although these practices constitute an interference, we note that the list is not exhaustive and other practices not described in this proposed new section will also constitute an interference for purposes of the information blocking definition.
                    </P>
                    <P>
                        We emphasize that these proposed provisions are practices that constitute an interference. We do not attempt to establish facts and circumstances in this proposed rule that would specify practices that are information blocking 
                        <PRTPAGE P="63618"/>
                        as the term is defined in § 171.103. For a practice to be information blocking, all elements of the definition must be met. This means that the individual or entity that engages in the practice must be an actor under the information blocking regulations; that the practice must be likely to interfere with the access, exchange, or use of EHI; and that the actor engaging in the practice meets the requisite knowledge standard. Further, “information blocking” does not include practices required by law or that meet an exception.
                    </P>
                    <P>In the ONC Cures Act Proposed Rule (84 FR 7424), we noted that the information blocking provision and its enforcement subsection in the 21st Century Cures Act do not define the terms “interfere with,” “prevent,” and “materially discourage.” Based on our interpretation of the information blocking provision, as discussed in the Cures Act Proposed Rule, we proposed to define “interfere with” and “interference” as preventing, materially discouraging or otherwise inhibiting access, exchange, or use of electronic health information (84 FR 7516, 7601). We finalized the definition in the ONC Cures Act Final Rule as proposed, but with a modification to remove the phrase “access, exchange, or use of electronic health information” as unnecessary and duplicative of the information blocking definition (85 FR 25642, 25809; see also 45 CFR 171.102). The preamble discussion of the definition of “interfere with” or “interference” in the ONC Cures Act Final Rule provides guidance explaining the meaning of these terms.</P>
                    <P>In the ONC Cures Act Proposed Rule, to further clarify the scope of the information blocking provision, we provided several examples of practices that would constitute interference. We refer readers to the ONC Cures Act Proposed Rule (84 FR 7518 through 7521) for discussion of those examples, which we also cited in the ONC Cures Act Final Rule (85 FR 25811). We refer readers to the ONC Cures Act Final Rule (85 FR 25811 through 25818) for additional examples of practices likely to interfere with access, exchange, or use of electronic health information (EHI) and additional discussion, including responses to public comments received on the ONC Cures Act Proposed Rule.</P>
                    <P>
                        Since publication of the ONC Cures Act Final Rule (May 1, 2020), we have provided additional guidance in the form of information blocking Frequently Asked Questions (FAQs). As of the time of publication of this proposed rule, we have posted 12 FAQs in the “Interference” category. Links to all categories of FAQs within the information blocking topic are available under the “Resources” heading of this page of ONC's website: 
                        <E T="03">https://www.healthit.gov/topic/information-blocking.</E>
                        <SU>230</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>230</SU>
                             The link to the 
                            <E T="03">interference</E>
                             category of FAQs directs to this URL: 
                            <E T="03">https://www.healthit.gov/faqs?f%5B0%5D=subtopic%3A7031.</E>
                             (Retrieved Apr. 9, 2024.)
                        </P>
                    </FTNT>
                    <P>
                        Certain practices have been brought to our attention through submissions to the Report Information Blocking Portal, questions we have received through the 
                        <E T="03">Health IT.gov</E>
                         Feedback and Inquiry Portal, and other interactions (including interactions with parties interested in learning more about seeking or providing access, exchange, or use of EHI).
                        <SU>231</SU>
                        <FTREF/>
                         Often, the party will present a hypothetical scenario and inquire if the practice constitutes information blocking. For a variety of reasons, ONC does not opine on whether a given practice constitutes information blocking. First, ONC does not have authority to offer binding advisory opinions.
                        <SU>232</SU>
                        <FTREF/>
                         Second, ONC cannot readily determine whether a scenario focused on a specific action or inaction generally constitutes information blocking because whether a practice meets the § 171.103 information blocking definition will involve an assessment of all the elements of the information blocking definition, as discussed above, and will be based on the facts and circumstances of each unique situation.
                    </P>
                    <FTNT>
                        <P>
                            <SU>231</SU>
                             Report Information Blocking Portal URL: 
                            <E T="03">https://inquiry.healthit.gov/support/plugins/servlet/desk/portal/6Health</E>
                             IT Feedback and Inquiry Portal URL: 
                            <E T="03">https://inquiry.healthit.gov/support/plugins/servlet/desk/portal/2</E>
                             Other interactions with interested parties include, for example, interactive discussion in various public venues, such as the “Ask Us About Information Sharing” sessions ONC has hosted since May 2020. (
                            <E T="03">https://www.healthit.gov/newsroom/past-events</E>
                            )
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>232</SU>
                             ONC requested but did not receive advisory opinion authority via the Congressional Appropriations Committee in fiscal years 2023 and 2024.
                        </P>
                    </FTNT>
                    <P>Informed by the concerns and questions that interested parties have brought to our attention, we propose to add § 171.104 to 45 CFR part 171 to codify that certain practices will constitute interferences for purposes of the information blocking definition.</P>
                    <P>
                        As previously noted, the practices we propose to codify are not an exhaustive list of all practices that constitute interferences. The practices in the proposed § 171.104 are intended to help regulated entities and other interested parties by codifying certain practices that constitute 
                        <E T="03">interferences</E>
                         for purposes of the information blocking definition. The practices we propose to codify include affirmative acts as well as omissions, because a practice, under the information blocking definition, can be “an act or omission committed by an actor.”
                    </P>
                    <P>The practices we propose to codify generally relate to:</P>
                    <P>• Actions taken by an actor to impose delays on other persons' access, exchange, or use of EHI;</P>
                    <P>• Non-standard implementation of health IT and other acts to limit interoperability of EHI or the manner in which EHI is accessed, exchanged, or used by other persons;</P>
                    <P>• Improper inducements or discriminatory contract provisions; and</P>
                    <P>• Omissions (failures to act). Some omissions which constitute interferences in the proposed § 171.104 include failures to publish (or make available for publication) technical information such as service base URLs for Certified API Technology. Other types of omissions include an actor's failure to fulfill requests for access, exchange, or use of EHI that is required by law, or failure to fulfill requests for access, exchange, or use of EHI when it is permitted by law and not inconsistent with any additional restrictions on access to the individual's EHI that the individual (patient) or their personal representative may have requested and that an actor agreed to honor.</P>
                    <P>In the proposed § 171.104(a)(3), we describe “delaying the access, exchange, or use of EHI to or by a third-party app designated and authorized by the patient when there is a deployed application programming interface (API) able to support the access, exchange, or use of the EHI.” In this paragraph and corresponding regulatory text (§ 171.104(a)(3)), the term “app,” as used in “third-party app,” describes any number of “applications” (or types of applications) a patient could use to access, exchange, or use their EHI—on their smart phone, computer, or smart watch, for example. These “apps” are able to communicate with other health information technology through an API (such as a Health IT Module certified to § 170.315(g)(10)) that permits EHI to be accessed and exchanged at the patient's direction.</P>
                    <P>
                        In the proposed § 171.104(a)(6), we note that certain non-compete clauses can implicate the information blocking definition. In the ONC Cures Act Proposed Rule, we stated that one means by which actors may restrict access, exchange, or use of EHI is through formal, contractual restrictions (84 FR 7518). We provided several examples of restrictive contractual clauses in that proposed rule (84 FR 7518). In the ONC Cures Act Final Rule, we acknowledged that many 
                        <PRTPAGE P="63619"/>
                        commenters stated that EHR developers place onerous contract terms on developers of applications that enable patient access to EHI through APIs (88 FR 25811). Regulated entities, software developers, and patient advocates have continued to express concerns to ONC about restrictive contractual clauses.
                    </P>
                    <P>Actors are placing conditions on access to EHI in the actor's health IT that are unrelated to security or privacy laws, and function as anti-competitive clauses that effectively prevent certain employees or contractors from accessing, exchanging, or using EHI in other health IT. Therefore, we propose to identify a particular type of contractual clause as an interference: negotiating or enforcing a clause in any agreement that prevents or restricts an employee (other than the actor's employees), contractor, or contractor's employee who accesses, exchanges, or uses the EHI in the actor's health IT from accessing, exchanging, or using EHI in other health IT in order to participate in the design, development, or upgrade of such other health IT. This proposal is intended specifically to make clear that it is an interference to prevent employees of an individual or entity (other than the actor's employees) from working on software development and design for both Company A (actor's company) and Company B, even if the companies are competitors or potential competitors, and even if the work is being conducted simultaneously. We note that this interference could be found in “any agreement,” even an agreement to which the actor is not a party, provided that the actor requires another party to include such a clause in that party's contracts with its employees or contractors. In addition, it is an interference for the actor to negotiate or enforce such a clause—again, in any agreement.</P>
                    <P>Recently, the Federal Trade Commission (FTC) finalized a nationwide ban on most non-compete clauses in any employment contract (89 FR 38342). The FTC noted that non-compete clauses have many deleterious effects, including on earnings, job creation, innovation, consumer prices, and new business formation (80 FR 38343). Although the FTC's rule would not cover the types of restrictions that are covered by our proposal, we believe such clauses have the same effects on health information technology by restricting the ability of developers to work on different software and to enter into new contracts at the same time that they are contracted to work with an actor's software. Although the contractual language at issue may occasionally be couched in language claiming to protect intellectual property, the clauses function as anti-competitive clauses and not as clauses protecting intellectual property from infringement or misappropriation. We note that in some cases, there are applicable laws that prevent employees and contractors from misusing intellectual property. Our proposal would not impact legally permissible intellectual property protections. In addition, we note that the Licensing Exception in § 171.303 acknowledges intellectual property rights, including the administration of a reasonable non-disclosure agreement that is no broader than necessary to prevent unauthorized disclosure of the actor's trade secrets.</P>
                    <P>We solicit comment on all aspects of our proposed description of the interference in § 171.104(a)(6). We specifically ask if we should add “including health IT for a competitor or potential competitor” at the end of the paragraph. We solicit comment on whether it is necessary to say “access, exchange, or use” or if “access or use” of EHI is sufficient. We specifically used the term “agreement” instead of “contract” because we recognize that such clauses can also be found in licensing agreements and other agreements that are not typically referred to as a contract. We also ask, more broadly, whether there are other types of agreements that should specifically be identified in the text of § 171.104(a)(6), such as those specified in the Cures Act rulemaking (84 FR 7518 and 88 FR 25811). Because we recognize that sometimes the actor induces a contractor to include the language in the agreement the contractor has with its employees, we use the phrase “negotiating or enforcing” to ensure that an actor inducing or forcing a customer, business associate, or any other entity to include such restrictions would also be considered an interference. We ask commenters to opine on whether “negotiating or enforcing” is broad enough to cover the situations intended to be covered by the description in § 171.104(a)(6), and whether any terms should be added to the definitions section of the regulation as a result of this or other descriptions of interferences in § 171.104.</P>
                    <P>We also solicit comments on the rest of the descriptions of interferences in the proposed § 171.104. Are the descriptions clear enough for regulated entities and those whose access, exchange, or use of EHI that might be adversely affected by the conduct to understand the intended policy? Are there other practices that interested parties believe should be explicitly identified in regulatory text as constituting interference? Would codification of more or fewer interferences be more helpful? In considering these questions, we remind readers that “interference” or “interfere with” includes practices that prevent, materially discourage, or otherwise inhibit the access, exchange, and use of EHI.</P>
                    <P>Finally, we reiterate and emphasize that the descriptions in the proposed § 171.104 are of conduct constituting “interference.” The facts and circumstances of an actor's engaging in any of these practices, or any other practice likely to interfere with access, exchange, or use of EHI, would determine whether the practice constitutes “information blocking.” OIG has the statutory authority to investigate allegations of information blocking and to determine whether information blocking has occurred.</P>
                    <HD SOURCE="HD3">
                        a. Application of “Interference” to TEFCA
                        <SU>TM</SU>
                         Requirements
                    </HD>
                    <P>
                        Having discussed practices that would be considered interferences, we want to take this opportunity to identify certain practices that we believe would be unlikely to interfere with the access, exchange, and use of EHI under the information blocking definition. Specifically, it would be unlikely to be an interference for Qualified Health Information Networks
                        <SU>TM</SU>
                         (QHINs), Participants, or Subparticipants to comply with required provisions of the Common Agreement and the incorporated terms of participation and standard operating procedures, respectively. In the ONC Cures Act Final Rule, we took a similar approach and identified certain practices that we believed would be unlikely to interfere with the access, exchange, and use of EHI. Specifically, we explained that an actor's practice that focused on educating individuals about the privacy and security risks posed by certain applications would be unlikely to rise to the level of an interference when certain conditions were met, and therefore would be unlikely to meet the definition of information blocking (85 FR 25815).
                    </P>
                    <P>
                        Many interested parties, directly and through responses to proposed rules and requests for information, have inquired about the implications of following requirements of the Trusted Exchange Framework and Common Agreement
                        <SU>TM</SU>
                         (TEFCA
                        <SU>TM</SU>
                        ), including the related terms of participation and standard operating procedures, with respect to the information blocking definition. In light of the concerns and questions that interested parties have brought to our attention with respect to TEFCA, we believe it is important to provide 
                        <PRTPAGE P="63620"/>
                        guidance to actors who are QHINS
                        <SU>TM</SU>
                        , Participants, or Subparticipants that practices they must undertake to comply with TEFCA requirements would be unlikely to rise to the level of an interference under the information blocking definition. We believe providing such guidance with respect to TEFCA requirements is important because when actors choose to access, exchange, and use EHI through TEFCA, their compliance with TEFCA requirements supports the policy goals of the Cures Act and information blocking regulations more broadly, such as to promote confidence in health IT infrastructure and interoperability (see 85 FR 25649, 25794, 25804, 25805, and 25806) by advancing interoperability and expanding secure access, exchange, and use of EHI. We also believe that because the proposed § 171.104 does not describe the full universe of practices that could constitute an interference, it is important to clarify that compliance with TEFCA requirements, in the context of TEFCA participation by a QHIN, Participant, or Subparticipant, is unlikely to constitute an interference under the information blocking definition.
                    </P>
                    <P>Actors who are QHINs, Participants, or Subparticipants have documents relevant to their participation in TEFCA, including documents such as the Common Agreement, terms of participation, and standard operating procedures. These documents may for example, establish certain standards to ensure the security of EHI, or on the manner of exchange of EHI.</P>
                    <P>
                        In certain cases, QHINs, Participants, or Subparticipants may engage in practices not specifically required by the Common Agreement, terms of participation, and standard operating procedures. Our guidance does not extend to such permissible or optional practices. To this point, not complying with 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), 
                        <E T="03">could</E>
                         be an interference, 
                        <E T="03">could</E>
                         implicate the information blocking definition, and would not be covered by the TEFCA Manner Exception (§ 171.403). Further, in general and for clarity, any practice (act or omission) between TEFCA entities that is not one specifically required by the Common Agreement, including its terms of participation and standard operating procedures, as well as any practice involving or affecting non-participants in TEFCA 
                        <E T="03">could</E>
                         also be an interference. For practices that are not required under TEFCA and/or that affect non-participants in TEFCA, which could constitute an interference, all of the other voluntary exceptions in part 171 would be available, as appropriate.
                    </P>
                    <P>We seek comments on our discussion. Does this discussion sufficiently reassure actors interested in participating in TEFCA that complying with the requirements of TEFCA as a QHIN, Participant, or Subparticipant would be unlikely to constitute “interference” under the information blocking definition? We also welcome comment on the desirability of further Federal guidance or education materials on the interaction between the information blocking regulations and the Common Agreement, including terms of participation and standard operating procedures.</P>
                    <HD SOURCE="HD2">B. Exceptions</HD>
                    <HD SOURCE="HD3">1. Privacy Exception</HD>
                    <HD SOURCE="HD3">a. Privacy Exception—Definition of Individual</HD>
                    <P>
                        For purposes of the Privacy Exception, the term “individual” is defined in § 171.202(a)(2). When the Privacy Exception in § 171.202 and paragraph (a)(2) were initially established by the ONC Cures Act Final Rule, the codified text included a typographical error that was not identified until after publication. In the ONC Cures Act Final Rule (at 85 FR 25957) and the current 
                        <E T="03">Code of Federal Regulations,</E>
                         the text of § 171.202(a)(2)(iii), (iv), and (v) cross-references paragraphs (a)(1) and (2) of § 171.202 instead of paragraphs (a)(2)(i) and (ii) when referencing a person who is the subject of EHI in defining the term “individual.” We now propose to make a technical correction to cross-references within the text of § 171.202(a)(2)(iii), (iv), and (v) to accurately cross-reference paragraph (a)(2)(i), (a)(2)(ii), or both, as applicable.
                    </P>
                    <P>
                        Paragraph (a)(2) of the current § 171.202 defines the term “individual” in part by referring to its definition in 45 CFR 160.103. In § 171.202(a)(2)(i), we cross-reference to the definition of “individual” as defined in the HIPAA Privacy Rule at 45 CFR 160.103. In (a)(2)(ii), we provide a second definition: “any other natural person who is the subject of the electronic health information being accessed, exchanged, or used.” 
                        <SU>233</SU>
                        <FTREF/>
                         Then, in (a)(2)(iii), (iv), and (v), we expand on those two definitions in order to include persons legally acting on behalf of such individuals or their estates in certain circumstances. However, the current text of § 171.202(a)(2)(iii), (iv), and (v) incorrectly references a “person described in paragraph (a)(1) or (2) of this section” instead of referencing a “person described in paragraph (a)(2)(i) or (ii) of this section.”
                    </P>
                    <FTNT>
                        <P>
                            <SU>233</SU>
                             The definition of “person” for purposes of 45 CFR part 171 is codified in § 171.102 and is, by cross-reference to 45 CFR 160.103, the same definition used for purposes of the HIPAA Privacy Rule (45 CFR part 160 and subpart E of 45 CFR part 164). The § 160.103 definition of “person” clarifies the meaning of “natural person” within it. We use “natural person” with that same meaning in § 171.202(a)(2) and throughout this discussion of § 171.202(a)(2).
                        </P>
                    </FTNT>
                    <P>The ONC Cures Act Final Rule preamble demonstrates our intent for the definition of “individual” in paragraph (a)(2) of § 171.202. Citing the ONC Cures Act Proposed Rule at 84 FR 7526, we stated in the ONC Cures Act Final Rule preamble (85 FR 25846 through 25847) that “the term `individual' encompassed any or all of the following: (1) An individual defined by 45 CFR 160.103; (2) any other natural person who is the subject of EHI that is being accessed, exchanged or used; (3) a person who legally acts on behalf of a person described in (1) or (2), including as a personal representative, in accordance with 45 CFR 164.502(g); or (4) a person who is a legal representative of and can make health care decisions on behalf of any person described in (1) or (2); or (5) an executor or administrator or other person having authority to act on behalf of the deceased person described in (1) or (2) or the individual's estate under State or other law.” Further, still referencing the ONC Cures Act Proposed Rule preamble, we wrote at 85 FR 25845 that “(3) encompasses a person with legal authority to act on behalf of the individual, which includes a person who is a personal representative as defined under the HIPAA Privacy Rule.” The paragraph designated as “(a)(3)” in the Proposed Rule at 84 FR 7602 and referenced simply as “(3)” in the discussion at 85 FR 25845 was designated as (a)(2)(iii) in § 171.202 as finalized at 85 FR 25957 and currently codified.</P>
                    <P>The quotes from the ONC Cures Act Final Rule preamble above demonstrate a consistent intention across the ONC Cures Act Proposed and Final Rules to cross-reference in the paragraphs finalized (at 85 FR 25957) and codified in § 171.202 as (a)(2)(iii), (iv), and (v) the paragraphs finalized and codified in § 171.202(a)(2)(i) and (ii). Accordingly, we propose the technical correction in the revised text of 45 CFR 171.202 to reflect the correct reading and intent.</P>
                    <P>
                        In drafting our proposed technical correction to § 171.202(a)(2), we determined that the cross-reference to (a)(2)(ii), a natural person who is the subject of the EHI being exchanged 
                        <E T="03">other than</E>
                         an individual as defined in 
                        <PRTPAGE P="63621"/>
                        45 CFR 160.103, is not needed in describing (in (a)(2)(iii)) a person acting as a personal representative in making decisions related to health care specifically in accordance with 45 CFR 164.502(g). This is because 45 CFR 164.502(g) pertains personal representatives of individuals as defined in 45 CFR 160.103 (persons who are the subject of PHI) under the HIPAA Privacy Rule. A person described in (a)(2)(i) is an individual as defined in 45 CFR 170.103 for purposes of the HIPAA Privacy Rule. However, (a)(2)(ii) describes “any 
                        <E T="03">other</E>
                         natural person who is the subject of the EHI being accessed, exchanged, or used” (emphasis added) rather than an “individual” who is the subject of PHI under the HIPAA Privacy Rule. Such 
                        <E T="03">other</E>
                         person (described in (a)(2)(ii)) would not have a person who is a “personal representative” specifically in accordance with the 45 CFR 164.502(g) provisions pertaining to “personal representatives” under the HIPAA Privacy Rule. Therefore, we propose to strike the unnecessary reference to § 171.202(a)(2)(ii) (a subject of EHI who does 
                        <E T="03">not</E>
                         meet the 45 CFR 160.103 (HIPAA Privacy Rule) definition of “individual”) from the § 171.202(a)(2)(iii) description of a person who acts as a personal representative specifically in accordance with the HIPAA Privacy Rule provisions in 45 CFR 164.502(g). By striking an unnecessary cross-reference, this proposal would simplify the regulatory text without changing what the § 171.202(a)(2) definition of “individual” means or how it applies in practice.
                    </P>
                    <HD SOURCE="HD3">b. Privacy Sub-Exception—Interfering With Individual Access Based on Unreviewable Grounds</HD>
                    <P>In the ONC Cures Act Final Rule (85 FR 25856), we finalized in § 171.202(d) a sub-exception to the Privacy exception applicable to the denial of an individual's request for electronic health information consistent with “unreviewable grounds” for denial of access under 45 CFR 164.524. As we explained in the ONC Cures Act Final Rule, these “unreviewable grounds” are related to specific privacy risks or interests and have been established for important public policy purposes, such as when a health care provider is providing treatment in the course of medical research or when a health care provider is acting under the direction of a correctional institution (85 FR 25856). (See 45 CFR 164.524(a)(2) for the full listing of circumstances in which individual may be denied access under 45 CFR 164.524 without the individual being provided an opportunity for review of the denial.)</P>
                    <P>
                        The current text of § 171.202(d) is explicitly applicable when an individual requests EHI under the HIPAA individual right of access standard (45 CFR 164.524(a)(1)) from an actor who must comply with this HIPAA Privacy Rule provision. Thus, the sub-exception is available only to actors who are also HIPAA covered entities or business associates.
                        <SU>234</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>234</SU>
                             
                            <E T="03">See</E>
                             the definitions of “covered entity” and “business associate” at 45 CFR 160.103.
                        </P>
                    </FTNT>
                    <P>
                        We explained how the sub-exception currently operates in the ONC Cures Act Final Rule preamble (see 85 FR 25856 through 25857). The current text of § 171.202(d) states that the actor's practice “must be consistent with 45 CFR 164.524(a)(2).” The preamble discussion of this sub-exception explains that an actor who chooses to deny the request must, to satisfy the § 171.202(d) sub-exception, meet the actor's obligations 
                        <SU>235</SU>
                        <FTREF/>
                         under the HIPAA Privacy Rule. Thus, if an actor who also must comply with 45 CFR 164.524(a)(1) denies, on unreviewable grounds, access to some or all of the protected health information (PHI) that is also EHI 
                        <SU>236</SU>
                        <FTREF/>
                         requested by the individual in compliance with the HIPAA Privacy Rule requirements, the denial is covered under the § 171.202(d) sub-exception as currently codified.
                    </P>
                    <FTNT>
                        <P>
                            <SU>235</SU>
                             At 85 FR 25856, we referred to the actor's HIPAA Privacy Rule compliance obligations in this situation as “its requirements.” We use more precise wording here for clarity.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>236</SU>
                             As defined in § 171.102 and excluding certain information as specified in subparagraphs (1) and (2) of this definition, EHI is electronic protected health information (ePHI) (defined in 45 CFR 160.103) that is or would be in the designated record set (defined in 45 CFR 164.501). It may be helpful for purposes of this discussion to think of EHI as a subset of PHI. The HIPAA right of access standard (45 CFR 164.524) applies to PHI that is not ePHI (
                            <E T="03">e.g.,</E>
                             paper records), but § 171.202 would be moot with respect to PHI that is not ePHI and therefore does not meet the EHI definition in § 171.102.
                        </P>
                    </FTNT>
                    <P>
                        We propose to broaden the applicability of the sub-exception so that it is available to any actor responding to a request for EHI where the circumstances set out in 45 CFR 164.524(a)(2)(i) through (v) apply, and not just for actors who are also HIPAA covered entities or business associates. Allowing the same information blocking sub-exception to cover a practice regardless of whether the actor engaging in the practice is also required to comply with the HIPAA Privacy Rule does not create a misalignment for actors who 
                        <E T="03">are</E>
                         subject to both the information blocking regulations and the HIPAA Privacy Rule. Instead, making this sub-exception available to all actors under the same conditions in which the sub-exception is available to HIPAA covered entities should reduce unnecessary variation across actors, improve compliance efficiency, and provide additional certainty as it relates to the applicability of this exception.
                    </P>
                    <P>We believe that broadening the applicability of the unreviewable grounds sub-exception (§ 171.202(d)) to practices by actors who are not required to comply with the HIPAA Privacy Rules will provide greater benefit to actors than creating unique requirements for the application of § 171.202(d) to such actors' practices in the circumstances set forth in § 164.524(a)(2). Actors who are not required to comply with the HIPAA Privacy Rule would need to familiarize themselves with up-to-date 45 CFR 164.524 implementation specifications that would apply to the actor's denial of access to the EHI in question in the circumstances set forth in § 164.524(a)(2) if the actor were a HIPAA covered entity or business associate. This is similar to such actors needing to familiarize themselves with the HIPAA Privacy Rule definitions for “ePHI” and “designated record set” (in §§ 160.103 and 164.501) for purposes of understanding the EHI definition in § 171.102. Actors who are not HIPAA covered entities or business associates and who want to obtain help in learning about denials of individual access in the circumstances specified in § 164.524(a)(2) could find a variety of educational sources to choose from. However, most health care providers, HIN/HIEs, health information management professionals, and health IT developers of certified health IT throughout the United States have experience complying with the HIPAA Privacy Rule.</P>
                    <P>
                        To clearly establish coverage of the § 171.202(d) sub-exception for all actors' practices under the same requirements, we propose to change the name of the sub-exception to: “interfering with individual access based on unreviewable grounds.” This proposed change to the header text is intended to express the expansion of the sub-exceptions' availability to all actors. Additionally, the proposed regulatory text would remove the current text's reference applying the sub-exception only to actors required to comply with the HIPAA right of access standards and only where the individual is making a request “under the right of access provision under 45 CFR 164.524(a)(1).” Instead, the proposed text would provide that the sub-exception applies where an individual requests their EHI from any actor in circumstances set 
                        <PRTPAGE P="63622"/>
                        forth in 45 CFR 164.524(a)(2). The proposed revision would, further, cross-reference the implementation specifications set out in 45 CFR 164.524 (access of individuals to protected health information) that HIPAA covered entities and business associates must already meet to comply with the HIPAA Privacy Rule when denying individual access on “unreviewable grounds” (45 CFR 164.524(a)(2)).
                    </P>
                    <P>We seek comments on this proposal.</P>
                    <HD SOURCE="HD3">c. Privacy Sub-Exception—Individual's Request Not To Share EHI</HD>
                    <P>We propose to slightly modify the header of § 171.202(e) for ease of reference to “individual's request not to share EHI.” More importantly, we propose to revise the sub-exception to remove the existing limitation that applies the exception only to individual-requested restrictions on EHI sharing that are permitted by other applicable law. The proposal would extend the availability of the § 171.202(e) sub-exception to an actor's practice of implementing restrictions the individual has requested on the access, exchange, or use of an individual's EHI even when the actor may have concern that another law or instrument could attempt to compel the actor to fulfill access, exchange, or use of EHI contrary to the individual's expressed wishes.</P>
                    <P>
                        The existing text and scope of 45 CFR 171.202(e) was established in 2020 by the ONC Cures Act Final Rule (85 FR 25642). When the sub-exception was finalized, health care providers and other actors did not raise explicit concerns regarding when they must comply with statutes, regulations, or instruments (such as subpoenas) issued under the laws of states in which they are not licensed, do not reside, and do not furnish care. In 2022, the Supreme Court decision in 
                        <E T="03">Dobbs</E>
                         v. 
                        <E T="03">Jackson Women's Health Organization</E>
                         overturned precedent that protected a constitutional right to abortion and altered the legal and health care landscape.
                        <SU>237</SU>
                        <FTREF/>
                         Since the Court's decision, across the United States, a variety of states have newly enacted or are newly enforcing restrictions on access to reproductive health care. The Court's ruling—and subsequent state restrictions—have had far-reaching implications for health care beyond the effects on access to abortion.
                        <SU>238</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>237</SU>
                             
                            <E T="03">See</E>
                             142 S. Ct. 2228.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>238</SU>
                             
                            <E T="03">See</E>
                             Melissa Suran, “Treating Cancer in Pregnant Patients After 
                            <E T="03">Roe</E>
                             v 
                            <E T="03">Wade</E>
                             Overturned,” JAMA (Sept. 29, 2022), (available at 
                            <E T="03">https://jamanetwork.com/journals/jama/fullarticle/2797062#:~:text=The%20US%20Supreme%20Court,before%20cancer%20treatment%20can%20begin),</E>
                             and Rita Rubin, “How Abortion Bans Could Affect Care for Miscarriage and Infertility,” JAMA (June 28, 2022), (available at 
                            <E T="03">https://jamanetwork-com.hhsnih.idm.oclc.org/journals/jama/fullarticle/2793921?resultClick=1).</E>
                             (URLs retrieved May 23, 2024.)
                        </P>
                    </FTNT>
                    <P>
                        In light of the changing landscape, we are concerned that actors might deny or terminate an individual's requested restrictions on sharing their EHI specifically due to uncertainty about whether the actor is aware of and can account for any and all laws that might override the individual's requested restrictions. An actor who might otherwise be inclined to agree to an individual's request not to share their EHI could be concerned about potential information blocking implications of honoring those individual requests in the face of demands for disclosure that 
                        <E T="03">might</E>
                         ultimately be enforced in a court of competent jurisdiction. In particular, we are concerned that actors may be unwilling to consider granting individuals' requests for restrictions, or may prematurely terminate some or all requested restrictions, based on uncertainty as to whether information blocking penalties or disincentives might be imposed in addition to costs the actor may incur to confirm whether the actor is, by other authority, compelled to provide access, exchange, or use of EHI despite the individual's wishes. For example, we understand actors are concerned about potentially implicating the information blocking definition by delaying a disclosure of EHI pursuant to a court order that the actor is aware is being contested, so that the actor can wait to see if the order will, in fact, compel the actor to make EHI available for access, exchange, or use contrary to the individual's request for restrictions to which the actor had agreed consistent with § 171.202(e). Accordingly, the removal of “unless otherwise required by law” from § 171.202(e) would be a useful complement to the existing Precondition Not Satisfied sub-exception (§ 171.202(b)) to help address actors' uncertainty about various state laws' applicability as they relate to information blocking. As currently codified, § 171.202(b) sub-exception of the Privacy Exception outlines a framework for actors to follow so that the actors' practices of not fulfilling requests to access, exchange, or use EHI would not constitute information blocking when one or more preconditions has not been satisfied for the access, exchange, or use to be permitted under applicable Federal and State, or Tribal laws.
                    </P>
                    <P>To be clear, the proposed revision to § 171.202(e) would not operate to override other law compelling disclosure against the individual's wishes. It would, however, offer actors who elect to honor individual requested restrictions certainty that applying those restrictions will not be considered information blocking so long as the actor's practices in doing so satisfy the requirements of the § 171.202(e) sub-exception. Whether the courts will or should apply any particular Federal, state, or Tribal law to any actor (or enforce orders issued under such laws to any actor in any particular circumstances) is beyond the scope of this proposal. If or where there may be a law that is enforced by a court with jurisdiction over the actor and subject matter and that requires a particular actor to fulfill access, exchange, or use of EHI without the individual's authorization, permission, or consent, the actor might be compelled to comply with that law independent of the information blocking statute and 45 CFR part 171. This would continue to be the case even if we were to finalize the proposed revision to § 171.202(e).</P>
                    <P>We also remind HIPAA covered entities and business associates that they must comply with the HIPAA Privacy Rule, including privacy protections in the HIPAA Privacy Rule to Support Reproductive Health Care Privacy Final Rule and any other applicable Federal laws that limit access, exchange, or use of EHI in particular circumstances. For example, an actor's practice likely to interfere with an individual's access, exchange, or use of EHI (as defined in 45 CFR 171.102) might satisfy an information blocking exception without fully satisfying the actor's separate obligations under 45 CFR 164.524 (HIPAA Privacy Rule's individual right of access). In such cases, an actor that is a HIPAA covered entity or business associate would be subject to penalties for violating the HIPAA Privacy Rule.</P>
                    <P>We welcome comments on this proposal.</P>
                    <HD SOURCE="HD3">2. Infeasibility Exception</HD>
                    <P>
                        In the ONC Cures Act Final Rule, ONC established the Infeasibility Exception (§ 171.204) (85 FR 25865 through 25870, and 85 FR 25958). Under the Infeasibility Exception, it is not considered information blocking if an actor, as defined in § 171.102, does not fulfill a request to access, exchange, or use EHI due to the infeasibility of the request, provided the actor satisfies at least two conditions: the § 171.204(b) 
                        <E T="03">responding to requests</E>
                         condition and 
                        <PRTPAGE P="63623"/>
                        any one of the conditions in § 171.204(a).
                    </P>
                    <P>In the HTI-1 Final Rule (89 FR 1436, see preamble at 89 FR 1373 through 1387), we finalized the following revisions to § 171.204:</P>
                    <P>
                        • clarification of the § 171.204(a)(1) 
                        <E T="03">uncontrollable events</E>
                         condition requirement that the uncontrollable event must have an actual negative impact on an actor's ability to fulfill EHI access, exchange, or use in order for 
                        <E T="03">uncontrollable events</E>
                         condition to apply;
                    </P>
                    <P>
                        • addition of two new conditions (
                        <E T="03">third party seeking modification use</E>
                         and 
                        <E T="03">manner exception exhausted,</E>
                         respectively subparagraphs (3) and (4)) under paragraph (a); and
                    </P>
                    <P>
                        • renumbering the 
                        <E T="03">infeasible under the circumstances</E>
                         condition from § 171.204(a)(3) to § 171.204(a)(5).
                    </P>
                    <P>
                        However, in the HTI-1 rulemaking, we did not change the substance of the 
                        <E T="03">infeasible under the circumstances</E>
                         condition (now codified in § 171.204(a)(5)) or the § 171.204(a)(2) 
                        <E T="03">segmentation</E>
                         condition, and we did not make any changes to § 171.204(b). In this rule, we propose to modify:
                    </P>
                    <P>
                        • the § 171.204(a)(2) 
                        <E T="03">segmentation</E>
                         condition as described in section IV.B.2.a;
                    </P>
                    <P>
                        • the § 171.204(a)(3) 
                        <E T="03">third party seeking modification use</E>
                         conditions as described in section IV.B.2.b; and
                    </P>
                    <P>
                        • the § 171.204(b) 
                        <E T="03">responding to requests</E>
                         condition as discussed in section IV.B.2.c (of this proposed rule).
                    </P>
                    <HD SOURCE="HD3">a. Segmentation Condition Modifications</HD>
                    <P>
                        The § 171.204(a)(2) 
                        <E T="03">segmentation</E>
                         condition currently applies where the actor is not able to fulfill a request for access, exchange, or use of EHI specifically because the actor cannot unambiguously segment from other requested EHI the EHI that cannot be made available by law or due to an individual's preference, or that may be withheld in accordance with § 171.201. In practice, “by law or due to an individual's preference” would include situations where: an actor has chosen to honor an individual's request for restrictions on sharing of some of their EHI; an individual's authorization or consent is a pre-requisite for a particular use or disclosure of their EHI to be lawful and the individual has not provided such authorization or consent; or law applicable in the circumstances of the request restricts sharing of the EHI.
                    </P>
                    <P>
                        We propose updates to the 
                        <E T="03">segmentation</E>
                         condition to enhance clarity and certainty, and to provide for its application to additional situations. We propose to update how the regulation text describes why certain EHI cannot or will not be made available, including more specific cross-references to relevant provisions within 45 CFR part 171.
                    </P>
                    <P>
                        Currently, the 
                        <E T="03">segmentation</E>
                         condition references (in subparagraph (i) of § 171.204(a)(2)) EHI that cannot be made available due to an individual's preference or by law, and (in subparagraph (ii) of § 171.204(a)(2)) EHI that the actor may choose to withhold in accordance with the Preventing Harm Exception. We propose to revise the condition (§ 171.204(a)(2)) as follows: to focus subparagraph (i) on EHI that is not permitted by applicable law to be made available, and to explicitly cross-reference in subparagraph (ii) the proposed Protecting Care Access Exception (§ 171.206) and the existing Privacy Exception (§ 171.202) in addition to the existing Preventing Harm Exception (§ 171.201) (which currently has an explicit cross-reference).
                    </P>
                    <P>
                        We believe that focusing § 171.204(a)(2)(i) solely on EHI that is not permitted by applicable law to be made available for a requested access, exchange, or use will reinforce for actors and other interested persons that actors cannot make EHI available when applicable law, such as the HIPAA Privacy Rule or 42 CFR part 2, does not permit covered information to be made available. Under our proposed revision of § 171.204(a)(2)(i), the 
                        <E T="03">segmentation</E>
                         condition would continue to apply as it does today when an actor cannot unambiguously segment EHI that, under applicable law, is permitted to be available to a particular person for a particular purpose from EHI that is not permitted to be available to that person for that purpose. This would include situations where the actor cannot unambiguously segment EHI for which preconditions for permitting use or disclosure under the HIPAA Privacy Rule (or other applicable law) have not been met from EHI for which such preconditions have been met, as well as scenarios where use or disclosure of specific EHI for a particular purpose is prohibited by applicable law.
                    </P>
                    <P>
                        The proposed revision to § 171.204(a)(2) would retain in subparagraph (ii) explicit reference to the Preventing Harm Exception (§ 171.201). Thus, the Infeasibility Exception's revised 
                        <E T="03">segmentation</E>
                         condition would continue to apply where the actor cannot unambiguously segment other EHI from EHI that the actor has chosen to withhold in accordance with the Preventing Harm Exception (§ 171.201).
                    </P>
                    <P>
                        We propose to explicitly add reference to § 171.202 in our revision to subparagraph (ii) of § 171.204(a)(2). This would ensure that the 
                        <E T="03">segmentation</E>
                         condition would continue to apply where the actor cannot unambiguously segment other EHI they could lawfully make available from EHI for which the actor has chosen to honor the individual's request not to share the EHI (consistent with § 171.202(e) sub-exception). In addition, citing § 171.202 in the proposed revision to subparagraph (ii) of § 171.204(a)(2) would expand explicit application of the § 171.204(a)(2) 
                        <E T="03">segmentation</E>
                         condition to certain situations where an actor subject to multiple laws with inconsistent preconditions adopts uniform privacy policies and procedures to adopt the more restrictive preconditions (as provided for under the Privacy sub-exception Precondition Not Satisfied, see § 171.202(b)(3) as currently codified). By referencing all of the Privacy Exception (§ 171.202), the proposed revised § 171.204(a)(2)(ii) would allow the Infeasibility Exception's 
                        <E T="03">segmentation</E>
                         condition to apply where an actor (who has adopted the more restrictive of multiple laws' preconditions for sharing of some information about an individual's health or care consistent with § 171.202(b)) cannot unambiguously segment EHI for which a more restrictive precondition has not been met from other EHI that the actor could lawfully share in the jurisdictions with less restrictive preconditions.
                    </P>
                    <P>
                        By referencing all of the Privacy Exception (§ 171.202), the proposed revision would also extend the 
                        <E T="03">segmentation</E>
                         condition's coverage to situations where the actor is unable to unambiguously segment EHI that could be made available from specific EHI that the actor may choose to withhold from the individual or their (personal or legal) representative consistent with the § 171.202(d) Privacy sub-exception “denial of individual access based on unreviewable grounds.”
                    </P>
                    <P>
                        We have identified a possibility that individuals and interested parties could be concerned that extending the 
                        <E T="03">segmentation</E>
                         condition's coverage could affect the speed with which actors move to adopt or improve segmentation capabilities. Segmentation capabilities may need to be improved to sequester the EHI that may be withheld from an individual on certain unreviewable grounds from 
                        <E T="03">other</E>
                         EHI an actor may have for that individual. For instance, in comparison to health information that may need to be sequestered for other reasons, different or additional segmentation functionality may be 
                        <PRTPAGE P="63624"/>
                        needed to sequester from other EHI only that information created or obtained in the course of research that includes treatment and only for as long as the research is in progress.
                        <SU>239</SU>
                        <FTREF/>
                         While the actor that is a HIPAA covered entity would still need to satisfy the individual's right of access to other PHI to the extent possible (see 45 CFR 164.524(d)(1)), the form and format in which the PHI is readily producible (see 45 CFR 164.524(c)(2)) may not be supported by the same electronic manner of access, exchange, or use that the individual would prefer. Therefore, we invite commenters to share any concerns or other perspectives they may wish to share relevant to this issue. We also propose in the alternative to reference only Privacy Exception sub-exceptions 
                        <E T="03">other than</E>
                         denial of access based on unreviewable grounds (§ 171.202(d)) in the revised § 171.204(a)(2) 
                        <E T="03">segmentation</E>
                         condition. Including this alternative proposal in this proposed rule means we could decide to finalize the revision to the § 171.204(a)(2) 
                        <E T="03">segmentation</E>
                         condition with or without cross-reference to (or that would include) “denial of access based on unreviewable grounds” (§ 171.202(d)).
                    </P>
                    <FTNT>
                        <P>
                            <SU>239</SU>
                             Please 
                            <E T="03">see</E>
                             45 CFR 164.524(a)(2)(iii) for the HIPAA Privacy Rule's full “unreviewable grounds for denial” circumstances to which this example alludes.
                        </P>
                    </FTNT>
                    <P>
                        For an actor's practice to be consistent with the § 171.202 Privacy Exception, the practice must meet the requirements set forth in any one of the sub-exceptions enumerated in § 171.202 (b) through (e). Referencing the entirety of § 171.202 in § 171.204(a)(2)(ii) would, therefore, also extend application of the Infeasibility Exception's 
                        <E T="03">segmentation</E>
                         condition to situations where a health IT developer of certified health IT that is not required to comply with the HIPAA Privacy Rule may withhold EHI they could otherwise lawfully make available based on an organizational privacy policy consistent with the § 171.202(c) sub-exception. (As used in § 171.202, “HIPAA Privacy Rule” means 45 CFR parts 160 and 164 (§ 171.202(a)(1).)
                    </P>
                    <P>
                        Because the § 171.202(c) sub-exception is applicable only where a health IT developer of certified health IT is not required to comply with the HIPAA Privacy Rule, it would apply in situations where the health IT developer of certified health IT is not required to comply with the individual right of access in 45 CFR 164.524. We believe it is possible that some individuals might seek health care or other services from such developers' customers (including health care providers) who are not HIPAA covered entities. In such situations, a State, or Tribal law may operate to provide the individual rights to access their health information that the actor has. (Determining what other laws may operate, or how, in specific circumstances is beyond the scope of this proposed rule.) Although the number of such situations may be relatively small, we do recognize it is possible for some individuals to find themselves in situations where no other law explicitly guarantees them a right to access EHI of which the individual is the subject (or the legal representative of the subject). In such situations, the individual may rely solely on the information blocking statute to ensure actors will not unreasonably and unnecessarily interfere with the individual's EHI access, exchange, or use. We are, therefore, interested in whether commenters may be concerned about potential unintended consequences of extending the (§ 171.204(a)(2)) 
                        <E T="03">segmentation</E>
                         condition to situations where a health IT developer is not required to comply with HIPAA and cannot segment EHI they have 
                        <E T="03">chosen</E>
                         to withhold consistent with the actor's own organizational privacy policies from other EHI. Would extending the 
                        <E T="03">segmentation</E>
                         condition to situations where a health IT developer has chosen to withhold EHI consistent with the Privacy sub-exception “health IT developer of certified health IT not covered by HIPAA” (§ 171.202(c)) pose too much risk of such developers avoiding individuals' EHI requests by choosing not to develop segmentation capabilities in the health IT they provide their customers who are not HIPAA covered entities? We welcome commenters' thoughts on this question. We also propose in the alternative to reference in the revised § 171.204(a)(2)(ii) 
                        <E T="03">segmentation</E>
                         condition only Privacy Exception sub-exceptions 
                        <E T="03">other than</E>
                         § 171.202(c) “health IT developer of certified health IT not covered by HIPAA” sub-exception. Including this alternative proposal in this proposed rule means we could decide to finalize the revision to the § 171.204(a)(2)(ii) 
                        <E T="03">segmentation</E>
                         condition with or without cross-reference to (or that would include) § 171.202(c) “health IT developer of certified health IT not covered by HIPAA.”
                    </P>
                    <P>
                        As discussed in section IV.B.3 of this preamble, the § 171.206 Protecting Care Access Exception would apply to practices that an actor chooses to implement that are likely to interfere with access, exchange, or use of specific EHI (including, but not limited to, withholding such EHI) when relevant conditions are met. We propose to reference § 171.206 in the proposed revised § 171.204(a)(2)(ii) because the proposed § 171.206(a) 
                        <E T="03">threshold</E>
                         condition's requirements include (among others) a requirement that the actor's practice be no broader than necessary to reduce the risk of potential exposure of any person(s) to legal action that the actor believes could arise from the particular access, exchange, or use of the specific EHI. The actor's lack of technical capability to sequester only the EHI for which relevant conditions of § 171.206 have been satisfied would not render § 171.206 applicable to interference with the lawful access, exchange, or use of other EHI pertaining to the same individual(s). Therefore, the proposed reference to § 171.206 in the proposed revised § 171.204(a)(2)(ii) would accommodate circumstances where an actor lacks the technical capability to unambiguously segment the EHI the actor has chosen to withhold consistent with the Protecting Care Access Exception (§ 171.206, if finalized) from other EHI that they could lawfully make available. The requirements for an actor's practice to satisfy the proposed new § 171.206 exception, including the § 171.206(a) 
                        <E T="03">threshold</E>
                         condition that would be relevant to any practice to which § 171.206 could apply as well as when the § 171.206(b) 
                        <E T="03">patient protection</E>
                         or § 171.206(c) 
                        <E T="03">care access</E>
                         conditions are relevant, are discussed in detail in section IV.B.3, below in this preamble.
                    </P>
                    <P>We solicit comments on these proposals.</P>
                    <HD SOURCE="HD3">b. Third Party Seeking Modification Use Condition Modifications</HD>
                    <P>
                        In the HTI-1 Final Rule (89 FR 1436) we excluded from applicability of the 
                        <E T="03">third party seeking modification use</E>
                         condition of the Infeasibility Exception (§ 171.204(a)(3)) a health care provider's requests for modification use from an actor that is its business associate. In the HTI-1 Final Rule, we noted that, for reasons stated in response to comments suggesting the condition's applicability exclusion may not be broad enough and in consideration of all comments on our discrete proposal, we did not expand the finalized exclusion from applicability of the condition as some commenters had requested (89 FR 1379). We also noted that we may consider amending the 
                        <E T="03">third party seeking modification use</E>
                         condition in the future if doing so may be appropriate (89 FR 1379). Upon further consideration, we now propose in § 171.204(a)(3)(ii) to extend the 
                        <PRTPAGE P="63625"/>
                        exclusion from applicability of the condition.
                    </P>
                    <P>
                        We now propose to revise the 
                        <E T="03">third party seeking modification use</E>
                         condition to designate the existing exclusion from the applicability of this condition as subparagraph (i) of § 171.204(a)(3), and within it change the words “health care provider” to “covered entity as defined in 45 CFR 160.103.” We propose this change because the HIPAA Privacy and Security Rules require that all covered entities and their business associates safeguard the privacy, security, and integrity of EHI, not just health care providers. As we noted in the HTI-1 Proposed Rule (88 FR 23866), covered entities and business associates often have a level of trust and contractual protections that reduce certain concerns, such as security and data provenance, that led us to propose the 
                        <E T="03">third party seeking modification use</E>
                         condition. In addition, as we noted in the HTI-1 Proposed Rule discussion of the limitation of this condition, covered entities and their business associates (as permitted by their business associate agreements) need to access and modify relevant EHI held by other business associates of those covered entities on a regular basis (88 FR 23866). Therefore, we believe the exclusion from applicability of this condition should encompass requests from all covered entities to their business associates.
                    </P>
                    <P>
                        We also propose to exclude from applicability of the condition requests from any health care provider (as defined in § 171.102), who is not a HIPAA covered entity (as defined in 45 CFR 160.103) but who is requesting modification use from an actor whose activities would make the actor a business associate of that same health care provider if that health care provider were a HIPAA covered entity. Even if a health care provider is not a HIPAA covered entity, a health care provider likely has obligations and responsibilities under State law 
                        <SU>240</SU>
                        <FTREF/>
                         and according to accreditation organizations' requirements 
                        <SU>241</SU>
                        <FTREF/>
                         and payers' requirements 
                        <SU>242</SU>
                        <FTREF/>
                         to keep and maintain medical records. Those responsibilities will likely require a health care provider to be able to regularly access and modify EHI held by entities who perform the functions of a business associate (as defined in 45 CFR 160.103) and would be considered a business associate of the health care provider if the health care provider were a covered entity. Further, it is our expectation that even if a health care provider is not a HIPAA covered entity and, therefore, does not have a HIPAA business associate agreement with an actor who maintains EHI or health IT system(s) or application(s) for the health care provider, the health care provider likely would have a pre-existing relationship with the actor similar to the relationship that a covered entity health care provider would have with their business associate, in terms of the existing level of trust, responsibilities, and obligations to handle EHI safely and securely. The health care provider who is not a HIPAA covered entity may be asking for modification use of EHI from an actor for the same purpose(s) that a health care provider who is a covered entity would be. We, therefore, propose to revise the 
                        <E T="03">third party seeking modification use</E>
                         condition by adding subparagraph (ii) of § 171.204(a)(3) that would exclude from applicability of the condition requests from health care providers (as defined in § 171.102) who are not HIPAA covered entities, requesting modification use from actors who would be considered the health care provider's business associate if the health care provider were a covered entity as defined in 45 CFR 160.103.
                    </P>
                    <FTNT>
                        <P>
                            <SU>240</SU>
                             
                            <E T="03">See, e.g., https://www.healthit.gov/sites/default/files/appa7-1.pdf</E>
                             (accessed Feb 26, 2024), and 
                            <E T="03">http://www.healthinfolaw.org/comparative-analysis/medical-record-retention-required-health-care-providers-50-state-comparison</E>
                             (accessed Feb 26, 2024).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>241</SU>
                             
                            <E T="03">See, e.g., https://www.jointcommission.org/standards/standard-faqs/home-care/leadership-ld/000001197/</E>
                             (accessed Feb 26, 2024).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>242</SU>
                             
                            <E T="03">See, e.g., https://www.cms.gov/files/document/mln4840534-medical-record-maintenance-and-access-requirements.pdf</E>
                             (accessed Feb 27, 2024), and 
                            <E T="03">https://www.healthdatamanagement.com/articles/how-to-craft-an-effective-record-retention-policy</E>
                             (accessed Feb 28, 2024).
                        </P>
                    </FTNT>
                    <P>We welcome comments on these proposals.</P>
                    <HD SOURCE="HD3">c. Responding to Requests Condition Modifications</HD>
                    <P>
                        The Infeasibility Exception currently includes as paragraph (b) of § 171.204 a 
                        <E T="03">responding to requests</E>
                         condition. To satisfy the Infeasibility Exception as a whole, an actor's practice must meet the requirements of the § 171.204(b) 
                        <E T="03">responding to requests</E>
                         condition in addition to meeting at least one of the conditions in § 171.204(a). To meet the § 171.204(b) 
                        <E T="03">responding to requests</E>
                         condition, if an actor does not fulfill a request for access, exchange, or use of EHI consistent with any of the conditions in paragraph (a) of § 171.204, then the actor must provide, within ten business days of receipt of the request, to the requestor a written reason(s) why the request is infeasible.
                    </P>
                    <P>
                        We propose to modify the § 171.204(b) 
                        <E T="03">responding to requests</E>
                         condition by establishing different timeframes for sending written responses to the requestor based on the § 171.204(a) condition under which fulfilling the requested access, exchange, or use of EHI is infeasible. The proposed revision to § 171.204(b) would retain the requirement that actors communicate to requestors “in writing the reason(s) why the request is infeasible” that we finalized in the ONC Cures Act Final Rule (85 FR 25958, preamble discussion at 85 FR 25869). Under this proposed revision, the condition would also continue to provide actors wishing to avail themselves of the Infeasibility Exception with discretion to decide the appropriate level of detail to include in their written responses (see 85 FR 25869). In addition, we do not propose to specify the format of the written response or a specific delivery mechanism (such as paper mail versus email). Therefore, the proposed revision would retain the condition's existing flexibility specific to the format of the written response. As is the case under the current text of § 171.204(b), meeting the proposed modified § 171.204(b) would be required in conjunction with meeting a condition in § 171.204(a) in order for an actor's practice to satisfy the § 171.204 Infeasibility Exception.
                    </P>
                    <P>
                        We did not propose to modify the 
                        <E T="03">responding to requests</E>
                         condition in the HTI-1 Proposed Rule, but we received comments on the proposed rule indicating that ten business days may not allow actors sufficient time to engage with requestors and fully evaluate all factors relevant to meeting certain conditions in § 171.204(a). We discussed such comments in reference to the 
                        <E T="03">manner exception exhausted</E>
                         condition (§ 171.204(a)(4)) in the HTI-1 Final Rule preamble (89 FR 1387). We noted in the preamble that we did not propose changes to the ten-day timeframe in the HTI-1 Proposed Rule and did not finalize any changes to paragraph (b) of § 171.204 in the HTI-1 Final Rule, but we stated that we may consider those comments in relation to future regulatory action. The concern that ten business days may not allow actors sufficient time to engage with requestors and fully evaluate all factors relevant to meeting certain conditions in § 171.204(a) has also been raised by various actors in both written informal correspondence and real-time interactions since the publication of the ONC Cures Act Final Rule (85 FR 25642). We have also received inquiries from these same actors as to what constitutes a “request” for purposes of the Infeasibility Exception. These inquiries specific to § 171.204(b) have generally centered on how we would 
                        <PRTPAGE P="63626"/>
                        determine when the ten-day “clock” for providing a written response begins.
                    </P>
                    <P>
                        We believe defining in regulation what constitutes a “request” or “actionable request” is unnecessary and could have more undesirable effects than desirable effects. We believe it would be difficult to define a single set of characteristics that every person's communication or conduct would need to satisfy before their communication to an actor, or other interaction with an actor or with health IT maintained or deployed by the actor, indicating the person seeks EHI access, exchange, or use would be considered a “request” for purposes of the information blocking regulations. Such specifications would increase complexity of the regulations and risk increasing rather than decreasing barriers to requestors' obtaining access, exchange, or use of EHI permitted under applicable law and, where applicable, consistent with patients' expressed individual preferences for privacy-protective restrictions beyond those required by law. In light of both experience over the four years since the ONC Cures Act Final Rule was published and the revisions that were finalized to the § 171.204(a) conditions in the HTI-1 Final Rule (89 FR 1436 through 1437, preamble discussion at 89 FR 1373 through 1387), we believe it remains appropriate to include as a condition of the Infeasibility Exception that the actor provide written responses within timeframes specified by the § 171.204(b) 
                        <E T="03">responding to requests</E>
                         condition. However, we have determined that the optimal timeframes to specify in § 171.204 going forward may vary based on the specific condition in § 171.204(a) that is satisfied.
                    </P>
                    <P>
                        We propose to retain, as new subparagraph (1) of § 171.204(b), the current § 171.204(b) requirement for a written response within ten business days of the actor receiving a request where the infeasibility of fulfilling requested access, exchange, or use of EHI satisfies the § 171.204(a)(1) 
                        <E T="03">uncontrollable events</E>
                         condition, § 171.204(a)(2) 
                        <E T="03">segmentation</E>
                         condition, or the § 171.204(a)(3) 
                        <E T="03">third party seeking modification use</E>
                         condition. We believe ten business days should be adequate time for an actor to recognize that a request that the actor has received, and that the actor might otherwise be able to fulfill, is not feasible in specific circumstances where an uncontrollable event has adversely impacted the actor's ability to fulfill the requested access, exchange, or use of EHI. Ten business days should also be sufficient for an actor to recognize that they cannot fulfill a request for EHI access, exchange, or use for reasons consistent with § 171.204(a)(2) 
                        <E T="03">segmentation</E>
                         condition or where a third party is seeking modification use in circumstances where § 171.204(a)(3) applies. However, we propose to revise the wording of the requirement from “receipt of” to “the actor receiving” to address what we believe some actors may experience as uncertainty regarding when one would start counting the ten business days in circumstances where fulfilling a request is infeasible for reasons consistent with § 171.204(a)(1).
                    </P>
                    <P>We recognize that there is significant variation in how people make requests and for what purposes, as well as the manners in which they seek to achieve access, exchange, or use of EHI. We also recognize that mechanisms and workflows for receiving and reviewing requests may vary, even within a single actor's operations, based on characteristics of the request. For example, fulfillment of patient requests for EHI access, exchange, or use that can be received and supported automatically via a cloud-based patient portal unaffected by a particular uncontrollable event would continue to be feasible even while the impact of an uncontrollable event on the actor's systems or operational status has rendered the actor unable to receive other requests from, for example, payers or health care providers.</P>
                    <P>An uncontrollable event's impact on a particular actor's systems or operational status may render it infeasible for the actor to receive some requests until a time when restoration or recovery efforts have progressed far enough that the actor's staff are able to access and use the actor's systems. For example, for some types of request and actor workflows, it may be necessary that: (1) application(s) involved in receiving and responding to requests for EHI access, exchange, and use are operational; and (2) appropriate staff are able to safely and securely log into and use the application(s). Once those two things are true again following an uncontrollable event, we would expect the actor's staff to resume receiving and appropriately dispositioning requests. By revising the wording to focus explicitly on the actor receiving the request, we hope the proposed revised wording will make it easier for actors to consider the distinction between requests that can be received and processed using only automated means and requests that require a human to do something—such as log into a system or obtain and open a piece of paper mail—in order for the actor to, in fact, receive the request.</P>
                    <P>Similarly, we believe revising the wording to focus on the actor receiving the request clarifies when the ten-day clock starts in scenarios where third parties seek modification use. From the point the actor receives the request, we believe ten business days is sufficient time for an actor to both determine and respond in writing to the requestor that the request is infeasible consistent with § 171.204(a)(3).</P>
                    <P>
                        In this proposed rule, we propose to define “business day” or “business days” in § 170.102 for purposes of the ONC Health IT Certification Program. For preamble discussion of this proposed definition of “business day” or “business days,” please see section III.D.1 of this proposed rule. We propose to adopt this same definition in § 171.102 for purposes of 45 CFR part 171. This proposal that is specific to the definition of “business day” or “business days” for purposes of 45 CFR part 171 is aligned with but is independent of the proposal to adopt the proposed definition of “business day” or “business days” discussed in section III.D.1 of this proposed rule for purposes of 45 CFR part 170. Therefore, commenters should be aware that we could choose to adopt the full proposed definition in § 171.102, instead of a cross-reference to § 170.102, for purposes of 45 CFR part 171 if we do not also adopt the definition for purposes of 45 CFR part 170. We welcome comment on this proposal specific to adoption of the definition (discussed in section III.D.1 and shown in the proposed revisions to § 170.102 in this proposed rule) for purposes of 45 CFR part 171 in general and as it would apply to the 
                        <E T="03">responding to requests</E>
                         condition of the Infeasibility Exception (§ 171.204(b)).
                    </P>
                    <P>
                        A proposed new subparagraph (2) in the proposed revised § 171.204(b) would apply where fulfilling a request is infeasible under the 
                        <E T="03">manner exception exhausted</E>
                         condition (§ 171.204(a)(4)) or the 
                        <E T="03">infeasible under the circumstances</E>
                         condition (§ 171.204(a)(5)). Under this proposal, the ten-day clock would start after the actor determines, without unnecessary delay and based on a reasonable assessment of the facts, that the requested access, exchange, or use of EHI cannot be provided consistent with § 171.301 or that fulfilling the request is infeasible under the circumstances. We expect that any actors who find themselves attempting to fulfill a request consistent with § 171.301 will be aware that the attempt to fulfill the request could instead result in infeasibility consistent with the § 171.204(a)(4) 
                        <E T="03">manner exception exhausted</E>
                         condition. Therefore, we 
                        <PRTPAGE P="63627"/>
                        expect that any such actor would, in good faith and without unnecessary delay, interact with the requestor to ascertain the scope and requested manner of EHI access, exchange, or use and negotiate any necessary fees and licensing consistent with § 171.301. Similarly, we expect that any actor who embarks on the consideration of factors in paragraph (i) of the 
                        <E T="03">infeasible under the circumstances</E>
                         condition (§ 171.204(a)(5)) will be aware that their consideration of these factors could lead to either a successful fulfilment of requested access, exchange, or use of EHI or a determination that complying with the request would be infeasible under the circumstances. Therefore, we expect the actor would, in good faith and without unnecessary delay, interact with the requestor to ascertain the scope and requested manner of EHI access, exchange, or use and obtain any additional information needed to support the actor's prompt consideration of the § 171.204(a)(5) factors.
                    </P>
                    <P>We welcome comments on this proposal.</P>
                    <P>We also propose in the alternative to enhance the revisions to § 171.204(b) by adopting either or both of the following requirements specific to the circumstances where § 171.204(b)(2) would be applicable.</P>
                    <P>• We propose an additional requirement for a specific maximum timeframe for the § 171.204(b)(2)(i) determination of infeasibility related to § 171.301. Under this additional requirement, the maximum timeframe would be one of the following: three, five, ten, twenty, or thirty business days.</P>
                    <P>• We propose an additional requirement that for § 171.204(b)(2) to be met, the determination and communication of infeasibility (for reasons consistent with § 171.204(a)(4) or (5)) would have to be made within the timeframe permitted under 45 CFR 164.524 for providing access to PHI where a request for EHI access, exchange, or use is one that implicates the HIPAA Privacy Rule's provisions for individual access to PHI (45 CFR 164.524) in addition to implicating the information blocking regulations in 45 CFR part 171.</P>
                    <P>We welcome comments on the possible additional requirements proposed above.</P>
                    <P>
                        Please note, if ONC adopts the alternative proposal above that specifically references 45 CFR 164.524 for purposes of § 171.204(b)(2), we intend to apply the timeframes required under that section when a request for individual EHI access, exchange, or use is received by the actor. Thus, under the alternative proposal's requirements that would limit maximum available response time under the 
                        <E T="03">responding to requests</E>
                         condition where the request for EHI implicates 45 CFR 164.524(a)(1) the timeframe would be limited to the timeframe required under 45 CFR 164.524. We also highlight for readers' awareness that HHS has proposed to revise 45 CFR 164.524(b)(2) to shorten the timeframes allowed to respond to individual requests for access to PHI (see 86 FR 6459 through 6460 and 86 FR 6535). In the event that changes to the 45 CFR 164.524 timeframes were to be finalized in a future HIPAA rule, the shorter timeframes would (upon becoming effective) apply to the alternative proposed additional requirement for responding to requestors where paragraph (b)(2) of the Infeasibility Exception would apply.
                    </P>
                    <HD SOURCE="HD3">3. Protecting Care Access Exception</HD>
                    <HD SOURCE="HD3">a. Background and Purpose</HD>
                    <P>As we explained in the ONC Cures Act Final Rule, the information blocking provision in PHSA section 3022 was enacted in response to concerns about practices that “unreasonably limit the availability and use of electronic health information (EHI) for authorized and permitted purposes” because such practices “undermine public and private sector investments in the nation's health IT infrastructure, and frustrate efforts to use modern technologies to improve healthcare quality and efficiency, accelerate research and innovation, and provide greater value and choice to healthcare consumers” (85 FR 25790). We also noted in the ONC Cures Act Final Rule that research suggests that information blocking practices “weaken competition among health care providers by limiting patient mobility” and “unnecessarily impede the flow of EHI or its use to improve health and the delivery of care” (85 FR 25791). As required by section 3022(a)(3) of the PHSA, we recognized that certain reasonable and necessary activities that could otherwise meet the definition of information blocking should not be considered information blocking, and therefore, established the initial eight “exceptions” to the definition of information blocking (see 45 CFR 171 Subpart B and C; a ninth exception was established by the HTI-1 Final Rule in Subpart D). Each reasonable and necessary activity identified as an exception to the information blocking definition does not constitute information blocking for purposes of section 3022(a)(1) of the PHSA if the conditions of the exception are met (85 FR 25649).</P>
                    <P>
                        Since the first eight regulatory exceptions to the information blocking definition were finalized in 2020 (see ONC Cures Act Final Rule, 85 FR 25642), the legal landscape has changed significantly for many patients seeking, and for health care providers providing, reproductive health care. In the wake of the decision in 
                        <E T="03">Dobbs</E>
                         v. 
                        <E T="03">Jackson Women's Health Organization,</E>
                         597 U.S. 215 (2022) decision, some States have newly enacted or are newly enforcing restrictions on access to reproductive health care. Uncertainties and other concerns that people who seek reproductive health care and people who provide or facilitate that care have about the legal landscape in the wake of the Supreme Court's ruling—and subsequent State restrictions on reproductive health care—have had far-reaching implications for health care beyond access to abortion. This changing legal landscape increases the likelihood that a patient's EHI may be disclosed in ways that erode trust in health care providers and the health care system, ultimately chilling an individual's willingness to seek, or other persons' willingness to provide or facilitate, lawful health care as well as individuals' willingness to provide full information to their health care providers.
                    </P>
                    <P>As a practical matter, a person's ability to access care of any kind depends on a variety of factors including whether the care is available. For health care to be available, licensed health care professionals and health care facilities must be willing to provide it—and people other than the licensed health care professionals must be willing to take on various roles essential to delivering care in this modern, technology-enabled environment. Also, patients' access to care may rely in some part on services or supports from other persons, such as a spouse or partner.</P>
                    <P>
                        In the current environment, various jurisdictions might enact legislation or attempt to enforce law that purports to authorize administrative, civil, or criminal legal action against persons who engage in reproductive health care that is required or authorized by Federal law or that is permitted by the law of the jurisdiction where the care is provided. Fear of being investigated or of having to defend themselves against potential legal liability under such laws, even where the health care provider or other person has reasonable confidence the defense will be successful, may impact people's willingness to provide or assist in reproductive health care that is lawful under the circumstances in which such health care is provided.
                        <PRTPAGE P="63628"/>
                    </P>
                    <P>On April 26, 2024, the HHS Office for Civil Rights (OCR) issued the “HIPAA Privacy Rule to Support Reproductive Health Care Privacy” final rule (89 FR 32976) (2024 HIPAA Privacy Rule) to adopt a prohibition on the use or disclosure of PHI by an entity regulated under the HIPAA Privacy Rule, in certain circumstances, for the following purposes:</P>
                    <P>• To conduct a criminal, civil, or administrative investigation into any person for the mere act of seeking, obtaining, providing, or facilitating lawful reproductive health care.</P>
                    <P>• To impose criminal, civil, or administrative liability on any person for the mere act of seeking, obtaining, providing, or facilitating reproductive health care.</P>
                    <P>• To identify any person for any purpose described above.</P>
                    <P>As noted in the National Coordinator's ONC Health IT blog post titled “Supporting Information Privacy for Patients, Now and Always: Four Reminders of How HHS Information Blocking Regulations Recognize Privacy Rules,” on and after the 2024 HIPAA Privacy Rule's effective date, a HIPAA covered entity's or business associate's practice of refusing to make a use or disclosure of PHI that is prohibited under that rule is excluded from the information blocking definition (45 CFR 171.103) because that refusal is required by law. Therefore, the practice does not need to be covered by any information blocking exception because it is not considered information blocking to begin with.</P>
                    <P>The 2024 HIPAA Privacy Rule also establishes a requirement for HIPAA covered entities and business associates to obtain attestations prior to using or disclosing PHI potentially related to reproductive health care for certain purposes (see 45 CFR 164.509 at 89 FR 33063). The Precondition Not Satisfied (45 CFR 171.202(b)) sub-exception of the information blocking Privacy Exception outlines a framework actors can follow so that the actors' practices of not fulfilling requests to access, exchange, or use EHI would not be considered information blocking when a precondition of applicable law has not been satisfied. By meeting the Precondition Not Satisfied sub-exception's requirements, the actor can have confidence that their practices of not sharing EHI because they have not obtained the required attestation will not be considered information blocking.</P>
                    <P>
                        The 2024 HIPAA Privacy Rule's new protections do not prohibit use or disclosure of PHI for various purposes other than those specified in 45 CFR 164.502(a)(5)(iii), though the protections include additional preconditions or limitations on disclosures for certain purposes (for more information, please see the 2024 HIPAA Privacy Rule (89 FR 32976) and consider visiting the HHS.gov Health Information Privacy section's HIPAA and Reproductive Health page: 
                        <E T="03">https://www.hhs.gov/hipaa/for-professionals/special-topics/reproductive-health/index.html</E>
                        ). The 2024 HIPAA Privacy Rule does not require a HIPAA covered entity or business associate to obtain the attestations specified in 45 CFR 164.509 before disclosing PHI (including PHI potentially related to reproductive health care) for permissible purposes other than those specified in 45 CFR 164.512(d), (e), (f), or (g)(1). For example, the HIPAA Privacy Rule continues to provide for uses and disclosures of PHI for treatment, payment or health care operations purposes (see 45 CFR 164.506) that do not meet any of the prohibitions set out in 45 CFR 164.524(a)(5)(iii). Thus, an actor choosing to deny requests for access, exchange, or use of EHI for a purpose permitted under HIPAA is not making a denial that is “required by law” specifically under HIPAA. As a result, the information blocking definition could be implicated unless another applicable law requires the denial or a regulatory exception applies. Similarly, an actor conditioning fulfilment of such requests on preconditions that an actor chooses to set (such as that the requestor provides an attestation that is not required by any privacy law that applies in the circumstances) could implicate the information blocking definition unless an exception applies to that practice.
                    </P>
                    <P>It may be helpful to pause here for a brief review of how the information blocking regulations, which are based on statutory authority separate from HIPAA, operate (independently of regulations promulgated under HIPAA). This background information may help readers understand how and why an actor may be concerned about potentially implicating the information blocking definition (and penalties or disincentives for information blocking authorized by the information blocking statute) if the actor engages in practices that the HIPAA Privacy Rule would require of a HIPAA covered entity or business associate when the actor is not required to comply with the HIPAA Privacy Rule.</P>
                    <P>
                        First, information blocking regulations 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 regulations in 45 CFR part 171, regardless of whether they are also a HIPAA covered entity (CE) or business associate (BA) as those terms are defined in 45 CFR 160.103. Second, for purposes of the information blocking regulations, the definition of “EHI” applies to information “
                        <E T="03">regardless</E>
                         of whether the group of records are used or maintained by or for a covered entity as defined in 45 CFR 160.103” (§ 171.102, emphasis added). Therefore, it is possible for an information blocking actor that is not required to comply with the HIPAA Privacy Rule to have EHI that is not also PHI. It is also possible for an actor (such as a HIN/HIE) to not be a HIPAA covered entity itself and to exchange, maintain, or otherwise handle EHI on behalf of network participants that are not required to comply with the HIPAA Privacy Rule.
                    </P>
                    <P>Where an actor that is not a HIPAA covered entity has EHI that is not maintained on behalf of a HIPAA covered entity, the actor may be concerned about potential information blocking consequences if the actor were to engage in a practice such as denying requests for access, exchange, or use of EHI that indicates or potentially relates to reproductive health care for purposes for which the 2024 HIPAA Privacy Rule would prohibit use or disclosure of PHI or would require an attestation as a precondition for permitting disclosure of PHI.</P>
                    <P>
                        There is a sub-exception within the Privacy Exception currently codified in § 171.202(c) that is available to a health IT developer of certified health IT “not covered by HIPAA.” The sub-exception is available “if the actor is a health IT developer of certified health IT that is not required to comply with the HIPAA Privacy Rule, when engaging in a practice that promotes the privacy interests of an individual” (§ 171.202(c), please see § 171.202(c) for the requirements to meet the exception.) However, this exception represents a departure from our general approach of designing each information blocking exception to be available to all actors (regardless of whether they must comply with the HIPAA Privacy Rule). The § 171.202(c) sub-exception is also not available to actors who meet the § 171.102 definition of “health care provider” or “HIN/HIE” even if they are not required to comply with the HIPAA Privacy Rule. (We refer actors and other persons interested in learning more about how the information blocking regulations, and particularly the 
                        <PRTPAGE P="63629"/>
                        exceptions, work in concert with the HIPAA Rules and other privacy laws to support health information privacy, to the discussion of this topic in the HTI-1 Final Rule at 89 FR 1351 through 1354.)
                    </P>
                    <P>We have come to understand that some health care providers and other actors may have concerns about the risk of potential exposure to legal action flowing from the uses and disclosures of EHI indicating or (in the case of patient health concern(s) or history) potentially relating to reproductive health care that remains permissible under applicable law. For example, the HIPAA Privacy Rule permits a HIPAA covered entity to disclose an individual's PHI to a health care provider who is not a HIPAA covered entity for treatment activities. Once PHI is in the possession, custody, or control of an entity that is not regulated under the HIPAA Privacy Rule, the information is no longer protected by the HIPAA Privacy Rule.</P>
                    <P>Thus, the HIPAA Privacy Rule's strengthened protections for PHI would not preclude a health care provider (or other recipient of PHI for other permissible purposes) who is not a HIPAA covered entity or business associate from further disclosing individually identifiable health information to someone who might then use the information to potentially impose criminal, civil, or administrative liability on any person for the mere act of seeking, obtaining, providing, or facilitating reproductive health care (or any other care) that was lawful under the circumstances in which it was provided.</P>
                    <P>We reiterate that the information blocking statute is separate from the HIPAA statute and that the information blocking regulations operate both separately and differently from the HIPAA regulations. One point of such difference that is key to understanding why we propose a new “Protecting Care Access Exception” (§ 171.206) is that a HIPAA covered entity or business associate is not required by the HIPAA Privacy Rule to make a use or disclosure that the rule merely permits. (The HIPAA Privacy Rule does require certain uses and disclosures of PHI but merely permit various other uses and disclosures.) Persons subject to the information blocking regulations, however, could implicate the information blocking definition if they “interfere with” any access, exchange, or use of EHI except as required by law or covered by an exception. It is the implication of the “information blocking” definition (and the potential to incur penalties or disincentives for engaging in information blocking) that would cause an actor to be concerned about, for instance, refusing to disclose EHI indicating reproductive health care for permissible purposes to an entity not required to comply with the HIPAA Privacy Rule and whom the actor has reason to believe does not safeguard the privacy or security of individuals' health information in compliance with the same standards as would be required of a HIPAA covered entity or business associate.</P>
                    <P>In a variety of situations where a patient or an actor may be concerned that an access, exchange, or use of EHI may implicate any person's physical safety interests or the individual's privacy interests, other exceptions (such as the Preventing Harm Exception in § 171.201 or three of the four sub-exceptions of the Privacy Exception in § 171.202) are available to any actor who wants to engage in practices that are likely to interfere with EHI access, exchange, or use consistent with the conditions of the applicable exception.</P>
                    <P>
                        Currently, however, there are no exceptions in 45 CFR part 171 that are designed to accommodate concerns an actor may have about a patient's, health care provider's, or other person's risk of potential exposure to legal action (investigation, action in court, or imposition of liability) that could arise from 
                        <SU>243</SU>
                        <FTREF/>
                         the access, exchange, or use for permissible purposes specific EHI (that is, one or more data points)that indicates reproductive health care was sought, obtained, provided, or facilitated. None of the current exceptions are designed to accommodate similar concerns an actor may have about risk of patients' potential exposure to legal action that could arise from the sharing for permissible purposes of EHI that indicates health condition(s) or history for which reproductive health care is often sought, obtained, or medically indicated.
                        <SU>244</SU>
                        <FTREF/>
                         Thus, where preconditions (under the HIPAA Privacy Rule or other applicable law—or both, where applicable) to the provision of access, exchange, or use of EHI have been met, and another exception (such as Privacy (§ 171.202) or Preventing Harm (§ 171.201)) does not apply, attempts to limit the disclosure of EHI for the purposes addressed in the 
                        <E T="03">patient protection</E>
                         or 
                        <E T="03">care access</E>
                         condition of the proposed Protecting Care Access Exception (§ 171.206(b) or (c)) could currently constitute information blocking. (An actor's practice will only meet the statutory or regulatory definition of information blocking if it meets all of the definition's elements, including the knowledge standard applicable to the actor engaged in the practice.)
                    </P>
                    <FTNT>
                        <P>
                            <SU>243</SU>
                             For purposes of this discussion and of the proposed Protecting Care Access Exception, a risk need not be one that is certain to occur, or that is likely to occur immediately following, an access, exchange, or use of EHI in order to be one that could arise from the access, exchange, or use.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>244</SU>
                             In this preamble, we at some points use for brevity and readability “potentially related to reproductive health care” as shorthand for EHI that shows or would carry a substantial risk of supporting an inference that (as described in proposed § 171.206(b)(1)(iii)) the patient has health condition(s) or history for which reproductive health care is often sought, obtained, or medically indicated.
                        </P>
                    </FTNT>
                    <P>
                        Even for actors to whom the HIPAA Privacy Rule does not apply, other laws (Federal, State, or Tribal) may apply preconditions that must be satisfied in order for EHI to be shared without violating these laws. For any actor, compliance with such other applicable law does not implicate the information blocking definition, as ONC has discussed in the HTI-1 Final Rule preamble (see 89 FR 1351 through 1354) and in information resources available on ONC's official website (
                        <E T="03">HealthIT.gov</E>
                        ). However, where the preconditions under such other applicable law are met, any practice by an actor that is likely to interfere with access, exchange, or use of EHI could implicate the information blocking definition (§ 171.103) unless the actor's practice is covered by an exception set forth in 45 CFR part 171.
                    </P>
                    <P>The proposed new Protecting Care Access Exception (§ 171.206) would be available to any actor, regardless of whether the actor is also a HIPAA covered entity or business associate. The proposed exception would apply regardless of whether another exception could also apply to an actor's practice(s) in relevant scenarios. Other exceptions would continue to be available in circumstances where the conditions of the Protecting Care Access cannot be met but the other exception(s) can be met. Each information blocking exception and each provision of each exception is designed to stand independent of any and every other exception unless any specific provision of an exception might explicitly reference another exception (even then the dependency is limited to the exact provision or function of such provision that relies upon the cross-reference).</P>
                    <P>
                        Thus, the proposed Protecting Care Access Exception would also operate independently of any provision of any other exception in part 171 and any provision in 45 CFR 171 that does not reference it. It is our intent that if any provision in § 171.206 were, if or when finalized, held to be invalid or unenforceable facially, or as applied to 
                        <PRTPAGE P="63630"/>
                        any person, plaintiff, or stayed pending further judicial or agency action, such provision shall be severable from other provisions of § 171.206 that do not rely upon it and from any other provision codified in 45 CFR part 171 that does not explicitly reference § 171.206 even if such provisions were to be established or modified through this same rulemaking action.
                    </P>
                    <P>A patient's ability to access care can be adversely affected when a provider believes they could be exposed to legal action based on the mere fact that care is provided. Given the demonstrated chilling effect of some States' laws on the availability of medically appropriate care, it is reasonable and necessary for actors to mitigate risks of potential exposure of health care professionals and other persons who provide or facilitate, as well as those who seek or obtain, reproductive health care that is lawful under the circumstances in which the care is provided to legal action based on the mere fact that such care was sought, obtained, provided, or facilitated. Thus, a new exception is needed to address actors' concerns about potentially implicating the information blocking definition (§ 171.103) if they choose not to share applicable EHI in the circumstances where the Protecting Care Access Exception (§ 171.206) would apply. This new proposed exception (§ 171.206) is important in order to ensure health care providers do not feel the need to adopt paper or hybrid recordkeeping methods in place of fully electronic, interoperable formats. Thus, we believe it is reasonable and necessary for an actor to restrict access, exchange, or use of specific EHI that indicates or (under § 171.206(b)) is potentially related to reproductive health care so that health care providers continue to use modern, interoperable health IT that better promotes patient safety than would paper or hybrid recordkeeping methods. Restricting EHI sharing under the conditions of the proposed new Protecting Care Access Exception (§ 171.206) is also necessary to preserve and promote public trust in health care professionals, health care, and the health information infrastructure.</P>
                    <P>
                        We propose the Protecting Care Access Exception to address actors' concerns about potentially implicating the information blocking definition if they choose not to share EHI in an EHI sharing scenario that an actor believes in good faith could risk exposing a patient, provider, or facilitator of lawful reproductive health care to potential legal action based on what care was sought, obtained, provided, facilitated, or (specific to the 
                        <E T="03">patient protection</E>
                         condition) is often sought, obtained, or medically indicated for the patient's health condition(s) or history.
                    </P>
                    <P>The HIPAA Privacy Rule does not prohibit the use or disclosure of PHI that indicates or is potentially related to “reproductive health care” as it is now defined in 45 CFR 160.103 (see 89 FR 32976 for definition effective June 25, 2024; see also 89 FR 33005 through 33007 for the 2024 HIPAA Privacy Rule's preamble discussion of that definition) where the use or disclosure is not for a purpose described at 45 CFR 164.502(a)(5)(iii) and where the use or disclosure is otherwise required or permitted by the HIPAA Privacy Rule. Therefore, within the information blocking regulations, the proposed new Protecting Care Access Exception is needed where an information blocking actor (whether or not that actor is required to comply with the HIPAA Privacy Rule) is concerned about the risk of potential exposure to legal action (as we propose in § 171.206(e) to define “legal action”) flowing from an access, exchange, or use of such EHI for a permissible purpose.</P>
                    <P>We recognize that no information blocking exception can address all of the concerns a person may have about potential legal action for the mere act of seeking, obtaining, providing, or facilitating reproductive health care. However, to the extent such concerns may be mitigated by actors' withholding relevant EHI from access, exchange, or use that all other applicable law would permit and where no other existing information blocking exception applies, we believe such withholding of EHI is reasonable and necessary. We are concerned that actors' uncertainty about whether such withholding of EHI could implicate the information blocking definition could prevent actors from withholding EHI unless an exception applies. Thus, we believe the Protecting Care Access Exception is needed to address actors' concerns specific to information blocking related to the risk of providers changing or limiting what care they are willing to offer (such as when a professional changes practice specialty or a hospital closes a service or department).</P>
                    <P>When providers limit what care they are willing to offer or what new patients they are willing to accept, it may be more difficult for those who seek care to get access to care they need. When patients' needs are not being met, they lose trust in the health care system and in their physicians. Trust in one's own physician, in general, correlates with better care satisfaction and outcomes. This could also be true of other types of health care providers. Thus, we believe that addressing actors' uncertainty specific to information blocking with the proposed Protecting Care Access Exception would promote better patient satisfaction and health outcomes as well as continued development, public trust in, and effective nationwide use of health information technology infrastructure to improve health and care.</P>
                    <P>Moreover, actors' uncertainty about the potential information blocking implications of not sharing all of the EHI that applicable laws would permit them to share could undermine health care professionals' (and other health care providers') confidence in their ability to protect the privacy and confidentiality of their patients' EHI. Such a lack of confidence on the part of health care providers can in turn erode a patient's trust.</P>
                    <P>Patient trust in physician confidentiality and competence is associated with patients being less likely to withhold information from doctors and more likely to agree it is important for health care providers to share information with each other. Thus, actors' narrowly tailored restrictions on (otherwise lawful) sharing of specific EHI in the circumstances addressed by the proposed exception in § 171.206 would be reasonable and necessary to preserve patient trust in the health IT infrastructure and information sharing, not just to protect the availability and safety of care and to promote better care outcomes.</P>
                    <P>One of the goals of the information blocking exceptions is “to accommodate practices that, while they may inhibit access, exchange, or use of EHI, are reasonable and necessary to advance other compelling policy interests . . .” including “[p]romoting public confidence in the health IT infrastructure by supporting the privacy and security of EHI and protecting patient safety,” as we explained in the ONC Cures Act Final Rule (85 FR 25791). In the absence of an information blocking exception applicable to risks of legal actions that actors believe could arise from the sharing EHI for permissible purposes (for instance, with entities not required to comply with the HIPAA Privacy Rule), we are concerned actors may be unwilling to engage in these practices that—for example—advance public confidence in health IT infrastructure and protect patient safety.</P>
                    <P>
                        If actors are unwilling to engage in such practices, health care providers may convey to patients an inability to withhold EHI even when they believe withholding the EHI could mitigate the potential risks cognizable under the 
                        <PRTPAGE P="63631"/>
                        Protecting Care Access Exception. If patients are aware that health care providers believe that they are unable to avoid sharing EHI to mitigate risks of potentially exposing care providers, recipients, or facilitators to legal action then patients may be less willing to be candid with their providers about their health history, conditions, or other information relevant to the patient's care. Without that candor, health care providers may be unable to provide care that will best meet the patient's needs.
                    </P>
                    <P>In addition, a care provider's lack of confidence or competence in their ability to adequately safeguard the privacy of information that care recipients share with them could erode the mutual trust that contributes to better care outcomes by promoting more effective relationships between care providers (including clinicians) and the individuals receiving care.</P>
                    <P>In the absence of an exception applicable to practices that the proposed Protecting Care Access Exception would cover, we are concerned that health IT developers of certified health IT and HINs/HIEs may be unwilling to take the actions necessary to address their own, or their customer health care provider's, good faith belief that particular sharing of specific EHI could create the risk of potential exposure of a health care provider (or persons seeking, obtaining, providing, or facilitating care) to legal action regarding health care items and services that are lawful under the circumstances in which such health care is provided. Thus, health care providers in these situations may believe they are faced with a choice between changing what care they offer (such as when a hospital closes a department) or switching at least some portions of their clinical records from electronic to paper formats specifically to avoid concerns that they may be engaged in information blocking.</P>
                    <P>For health care professionals in reproductive health care specialties or whose practice necessarily includes patients who need reproductive health care, a partial or complete switch to paper-based recordkeeping for that care may seem like their only option. (Because the information blocking definition references “electronic health information” rather than all “protected health information,” the information blocking regulations do not apply to health information maintained only in paper format.)</P>
                    <P>A reversal to paper-based methods of keeping even a relatively small portion of the records currently managed using modern health IT would have an adverse effect on interoperability and on the development of a nationwide health IT infrastructure that does the things identified in section 3001(b) of the PHSA. Thus, such a reversal to paper-based recordkeeping methods would impede the goals of promoting public confidence in the electronic health information infrastructure and of advancing patient safety through the use of interoperable health IT and EHI. For example, information kept only on paper is not available to support tools that help clinicians avoid adverse drug events by automatically checking for potential drug-drug or drug-allergy interactions.</P>
                    <P>For the reasons discussed above, we believe actors' practices of limiting EHI sharing under the conditions of the proposed § 171.206 exception are reasonable and necessary to preserve advances in digitization, interoperability, and public confidence in the nationwide health information technology infrastructure. Actors selectively withholding EHI that indicates or is potentially related to reproductive health care (as applicable) under the conditions of the proposed § 171.206 would also promote patient safety and improve outcomes by fostering trust between care providers and recipients. Maintaining advances and trust in the health information technology infrastructure fosters better care by continuing to make information available to more care providers and care recipients when and where the information can help them choose the right care for each patient (care recipient). Use of interoperable, electronic health IT and exchange of EHI also enables providers to use decision support tools, such as drug-drug interaction alerting, and to deliver better care.</P>
                    <P>The proposed Protecting Care Access Exception (§ 171.206) could apply in some circumstances where another exception (such as Preventing Harm (§ 171.201) or Privacy (§ 171.202)) would or could also apply. The proposed new exception is, however, intended to stand alone and independent of other. The proposed Protecting Care Access Exception would not affect if, how, or when any provision of any exception that does not explicitly reference § 171.206 applies to an actor's practice, or how any such provision operates. Moreover, where facts and circumstances were such that an actor could choose to shape their practice in withholding EHI to satisfy either the Protecting Care Access Exception (if finalized) or another exception, the actor would have discretion to choose which exception they wish to satisfy. An actor's practice in such situation(s) would not need to satisfy both exceptions in order for the practice to not be considered information blocking.</P>
                    <P>One of the existing information blocking exceptions applicable in some circumstances where the proposed Protecting Care Access Exception could also apply is the Privacy Exception. Of particular relevance to actors' confidence that they will not be “information blocking” if they withhold EHI based on the individual's preference that their EHI be closely held is the Privacy Exception's sub-exception “respecting an individual's request not to share information” (§ 171.202(e)).</P>
                    <P>This Privacy sub-exception is applicable where an actor agrees to honor an individual's request not to share their EHI even where it is permissible to share under all applicable law. We are proposing to strengthen and simplify that § 171.202(e) Privacy sub-exception as discussed in section IV.B.1.c of this proposed rule. The § 171.202(e) sub-exception offers actors certainty that they can, if they so choose, honor an individual's preference for restrictions on the sharing of EHI about the individual without subjecting the actor to an information blocking penalty or disincentive for not sharing such EHI. However, while the § 171.202(e) sub-exception does not rest on why the individual may prefer that some or all of their EHI not be shared, the § 171.202(e) sub-exception only applies to scenarios where the individual requests the restrictions. There may be circumstances where an individual does not request the restriction, but when it would be reasonable and necessary for actors to interfere with access, exchange, or use of EHI for the purpose of addressing individuals' (let alone providers' and others') risk of potential exposure to legal action that could discourage availability, access, and choice of medically appropriate reproductive health care.</P>
                    <P>
                        We believe it would be burdensome to individuals, in the constantly changing legal landscape, to rely exclusively on them to make or update requests for restrictions on their EHI that indicates or is potentially related to reproductive health care. In such a complex and uncertain environment, any individual may experience difficulty in making timely requests for such restrictions. Moreover, some individuals may not have the resources—such as affordable, secure access to the internet—to update their providers on their information sharing preferences outside of the occasions that they interact with these providers to obtain health care. Thus, individuals may not be able to request 
                        <PRTPAGE P="63632"/>
                        restrictions soon enough, or that are broad enough, to protect themselves or others from potential legal liability based on what care they have received.
                    </P>
                    <P>An individual's request for restrictions on sharing their EHI is specific and limited to that individual's EHI, and (depending on what the individual chooses to request) may be specific to identified requestors of the individual's EHI. Thus, it is not as efficient for actors to implement such individual restrictions as it would be to implement restrictions based on an organizational policy that consistently addresses a concern common to sharing any individuals' EHI in a particular access, exchange, or use scenario—such as the actor's good faith belief that there is a concern regarding the risk of potential exposure to legal action that could be created or increased by propagating to a recipient not required to comply with the HIPAA Privacy Rule the specific EHI within a patient's record that indicates the receipt of reproductive health care.</P>
                    <P>
                        For these reasons, we believe that health care providers and other actors must have available to them an information blocking exception designed to apply to practices that the actor believes could help to avoid creating—through sharing of EHI indicating or potentially related to reproductive health care in relevant scenarios—a risk of potential exposure to legal action based on the mere fact that lawful reproductive health care was sought, obtained, provided, or facilitated (or where the proposed 
                        <E T="03">patient protection</E>
                         condition would apply, because the EHI indicates patient health history or condition(s) for which reproductive health care is often sought, obtained, or medically indicated).
                    </P>
                    <P>
                        When an actor has a belief consistent with the proposed § 171.206(a)(1) belief requirement, we believe an exception should be available that is designed to cover practices likely to interfere with access, exchange, or use of EHI under certain conditions.
                        <SU>245</SU>
                        <FTREF/>
                         Therefore, we propose in § 171.206 a new Protecting Care Access Exception from the information blocking definition. When its conditions are met, the new exception would cover an actor's practices that interfere with access, exchange or use of EHI in order to reduce potential exposure of applicable persons to legal action (as defined in the exception). For the proposed exception to apply, the potential exposure to legal action that the actor believes could be created must be one that would arise from the fact that reproductive health care was (or may have been) sought, obtained, provided, or facilitated rather than because the care provided was (or is alleged to have been) clinically inappropriate or otherwise substandard.
                    </P>
                    <FTNT>
                        <P>
                            <SU>245</SU>
                             These conditions would be those specified in the exception.
                        </P>
                    </FTNT>
                    <P>We note here that the statutory authority in PHSA section 3022(a)(3) is to “identify reasonable and necessary activities that do not constitute information blocking.” Thus, practices that meet the applicable conditions of the proposed new Protecting Care Access Exception (§ 171.206) would not be considered information blocking (as defined in PHSA section 3022(a)(1) and 45 CFR 171.103), and, therefore, actors would not be subject to civil monetary penalties or disincentives under HHS information blocking regulations based specifically on those practices.</P>
                    <P>
                        However, as is the case with exceptions already established in 45 CFR part 171, the proposed exception would not override an actor's obligation to comply with a mandate contained in law that requires disclosures that are enforceable in a court of law. For example, the proposed exception would not invalidate otherwise valid court-ordered disclosures, or disclosures (for example, infectious disease, or child or elder abuse case reports) mandated by a Federal, State, or Tribal law with which an actor is required to comply in relevant circumstances. The exception is also not intended to justify an attempt to limit the legally required production of (otherwise discoverable) EHI in a civil, criminal, or administrative action that is brought in the jurisdiction where a health care provider provided health care that a patient (or their representative) alleges was negligent, defective, substandard, or otherwise tortious. Similarly, the exception would not apply to, and is not intended to justify, attempts to avoid disclosing information where the actor's belief is that the information could be useful to a legal action against the actor or other person specific to alleged violations of Federal or other law against conduct other than merely seeking, receiving, providing, or facilitating reproductive health care. One example of such other conduct would be a physical assault of any natural person, even if the assault occurred in a health care setting.
                        <SU>246</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>246</SU>
                             The definition of “person” for purposes of 45 CFR part 171 is codified in § 171.102 and is, by cross-reference to 45 CFR 160.103, the same definition used for purposes of the HIPAA Privacy Rule (45 CFR part 160 and subpart E of 45 CFR part 164). The § 160.103 definition of “person” clarifies the meaning of “natural person” within it. We use “natural person” with that same meaning in proposed § 171.206(b)(3) and throughout this discussion of proposed § 171.206.
                        </P>
                    </FTNT>
                    <P>We emphasize that if the proposed Protecting Care Access Exception were to be finalized, actors would continue to be subject to other Federal laws, and to State and Tribal laws. This is consistent with how the information blocking exceptions in place today operate in harmony with, but separate from, requirements of other statutes and regulations—including, among others, the HIPAA Privacy Rule's individual right of access (45 CFR 164.524).</P>
                    <P>For example, an actor that is also a HIPAA covered entity may receive a request from an individual for access to EHI of which the individual is the subject, in a manner (form and format) specified by the individual. If the actor is technically unable to fulfill the request, or if the individual and actor cannot come to agreement on terms to fulfill the request in the manner requested or an alternative manner consistent with § 171.301(b), the actor may be able to satisfy the Infeasibility Exception by meeting that exception's manner exception exhausted (§ 171.204)(a)(4)) and the responding to requests (§ 171.204(b)) conditions. By satisfying the Infeasibility Exception, the actor's practice of failing to fulfill the request for access, exchange, or use of EHI will not be considered information blocking. However, the actor in this example is a HIPAA covered entity and, therefore, must comply with the HIPAA Privacy Rule's right of access at 45 CFR 164.524, even though the actor's practices in failing to provide access, exchange, or use of EHI met the requirements to be covered by the Infeasibility Exception (§ 171.204) for purposes of the information blocking regulations.</P>
                    <P>
                        Consistent with our approach to establishing the initial eight information blocking exceptions, the conditions of the proposed Protecting Care Access Exception (§ 171.206) are intended to limit its application to the reasonable and necessary activities enumerated within the exception. Therefore, our proposed Protecting Care Access Exception would (for purposes of the information blocking definition in § 171.103) cover an actor's practice that is implemented to reduce potential exposure of persons meeting the § 171.202(a)(2)(i) or (ii) definition of “individual,” other persons referenced or identifiable from EHI as having sought or obtained reproductive health care, health care providers, or persons who facilitate access to or delivery of health care to potential threats of legal action based on the decision to seek, obtain, provide, or facilitate reproductive health care, or on patient health information potentially related to 
                        <PRTPAGE P="63633"/>
                        reproductive health care, subject to the exception's conditions.
                    </P>
                    <P>
                        Because we propose in this rule an exception that relies on the “reproductive health care” definition in 45 CFR 160.103, we also propose to add to § 171.102 the following: “Reproductive health care is defined as it is in 45 CFR 160.103.” We refer readers to 45 CFR 160.103or 89 FR 32976 for that definition, which became effective for purposes of the HIPAA Privacy Rule on June 25, 2024.
                        <SU>247</SU>
                        <FTREF/>
                         We refer readers interested in learning more about this definition to 89 FR 33005 through 33007 for the 2024 HIPAA Privacy Rule's preamble discussion of the “reproductive health care” definition.
                    </P>
                    <FTNT>
                        <P>
                            <SU>247</SU>
                             The addition of the “reproductive health care” definition to 45 CFR 160.103 is reflected in the Electronic Code of Federal Regulations (eCFR) system at 
                            <E T="03">https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-160/subpart-A/section-160.103</E>
                             at the time this proposed rule (HTI-2) is issued. The annual revision of the published Title 45 occurs on October 1. (The eCFR is a continuously updated online version of the CFR. Please 
                            <E T="03">see</E>
                             the following website for more information about the eCFR system: 
                            <E T="03">https://www.ecfr.gov/reader-aids/using-ecfr/getting-started</E>
                            .)
                        </P>
                    </FTNT>
                    <P>
                        For this exception to apply to an actor's practice that is likely to interfere with EHI access, exchange, or use, the practice would have to satisfy the 
                        <E T="03">threshold</E>
                         condition in the proposed paragraph (a), and at least one of the other conditions (proposed paragraph (b) or (c)) of the proposed exception. These conditions are discussed in detail below. An actor's practice could satisfy both conditions (b) and (c) at the same time, but the minimum requirement for the exception to apply would be that the practice satisfy at least one of these two conditions in complement to the 
                        <E T="03">threshold</E>
                         condition in paragraph (a).
                    </P>
                    <HD SOURCE="HD3">b. Threshold Condition and Structure of Exception</HD>
                    <P>
                        The § 171.206(a) 
                        <E T="03">threshold</E>
                         condition's requirements must be satisfied in order for any practice to be covered by the proposed exception. To meet the condition's subparagraph (a)(1) belief requirement, the practice must be undertaken based on a good faith belief that:
                    </P>
                    <P>• the person(s) seeking, obtaining, providing, or facilitating reproductive health care are at risk of being potentially exposed to legal action that could arise as a consequence of particular access, exchange or use of specific EHI; and</P>
                    <P>• the practice could reduce that risk.</P>
                    <P>To satisfy the belief requirement (§ 171.206(a)(1)), the actor's belief need not be accurate, but must be held in good faith. We are also considering, and seek comment, on whether actors, patients, or other interested parties may view “good faith belief” as a standard that is unnecessarily stringent or that could make the Protecting Care Access Exception difficult for small actors with limited resources, such as small and safety net health care providers, to confidently use. We are also interested in any thoughts or concerns commenters may have about the “good faith belief” standard and how such concerns could be mitigated by the addition to § 171.206 of a presumption that an actor's belief is held in good faith.</P>
                    <P>To ensure we have flexibility to do so in case we determine it is the optimal approach after considering public comments on the proposed Protecting Care Access Exception, we propose in the alternative to do one or both of the following: (1) set “belief” or “honest belief” rather than “good faith belief” as the substantive standard in § 171.206(a); or (2) add to § 171.206 a provision for HHS to presume an actor's belief met the standard unless we have or find evidence that the actor's belief did not meet the standard at all relevant times (relevant times are those when the actor engaged in practices for which the actor seeks application of the exception).</P>
                    <P>Like “good faith belief,” “belief” or “honest belief” would be a subjective rather than an objective standard. Under either alternative, the actor's belief would not be required to be accurate but could not be falsely claimed. Unlike “good faith,” neither “belief” nor “honest belief” is a particularly long established and widely used legal standard. However, we are interested in actors' and other commenters' views on whether these standards might help to reduce potential misunderstanding of § 171.206(a) and what would be necessary for an actor to meet the proposed “good faith belief” standard.</P>
                    <P>Where an actor is a business associate of another actor or otherwise maintains EHI on behalf of another actor, this exception would (where its requirements are otherwise fully satisfied) apply to practices implemented by the actor who maintains EHI based on the good faith belief and organizational policy or case-by-case determinations of the actor on whose behalf relevant EHI is maintained. We propose in the alternative to require that each actor rely only on their own good faith belief in order to implement practices covered by the Protecting Care Access Exception, including when an actor maintains EHI on behalf of other actor(s) or any other person(s). We welcome comment on both of these approaches to the good faith belief requirement where the actor implementing the practice is doing so in relation to EHI maintained on behalf of another actor.</P>
                    <P>As discussed in section IV.B.3.e, we propose to define “legal action” for purposes of § 171.206 to include a broad array of criminal, civil, and administrative investigations, actions, and proceedings as specified in the proposed § 171.206(e)(1)-(3).</P>
                    <P>
                        We emphasize that to satisfy the proposed Protecting Care Access Exception, an actor's practice that is likely to interfere with lawful access, exchange, or use of EHI would need to fully satisfy relevant requirements of the 
                        <E T="03">threshold</E>
                         condition in § 171.206(a) and at least one of the other two conditions (§ 171.206(b) or § 171.206(c)).
                        <SU>248</SU>
                        <FTREF/>
                         Thus, a practice could not satisfy the exception if implemented based on an actor's good faith belief about any access, exchange, or use (that is permitted under HIPAA Privacy Rule and any other applicable privacy law) that potentially creates or increases anyone's risk of facing any legal action that would not be based upon a person having merely sought, obtained, provided, or facilitated care that was lawful under the circumstances in which such health care was provided. The exception is not intended to apply to an actor's interference with access, exchange, or use of EHI based on an actor's belief that the practice would reduce any person's exposure to legal action or liability based on the conduct that was not the mere act of seeking, obtaining, providing, facilitating, or (where the 
                        <E T="03">patient protection</E>
                         condition applies, potentially needing) reproductive health care that was, under the circumstances in which the conduct occurred, unlawful.
                    </P>
                    <FTNT>
                        <P>
                            <SU>248</SU>
                             In relevant circumstances, an actor's practice might meet 
                            <E T="03">both</E>
                             the § 171.206(b) 
                            <E T="03">patient protection</E>
                             and § 171.206(c) 
                            <E T="03">care access</E>
                             conditions simultaneously. But each of these conditions could also apply in circumstances where the other does not. Thus, the proposed exception is intended and designed to apply where either or both of the 
                            <E T="03">patient protection</E>
                             and 
                            <E T="03">care access</E>
                             conditions are met in complement to the § 171.206(a) 
                            <E T="03">threshold condition</E>
                            .
                        </P>
                    </FTNT>
                    <P>
                        The belief requirement (subparagraph (1)) of the 
                        <E T="03">threshold</E>
                         condition (§ 171.206(a)) would ensure that the exception is applicable only in situations where an actor has a good faith belief that their practice of interfering with the access, exchange, or use of EHI that indicates the seeking, obtaining, providing or facilitating of reproductive health care (not with EHI access, exchange, or use in general or universally) could reduce a risk of potential exposure to legal action against identifiable persons that could otherwise arise as a consequence of the 
                        <PRTPAGE P="63634"/>
                        particular access, exchange or use of specific EHI that is affected by the practice. To satisfy the § 171.206(a)(1) requirement, the actor's good faith belief would need to be that persons seeking, obtaining, providing, or facilitating reproductive health care “are at risk” of being potentially exposed to legal action. This does not mean that the exception would apply only where the actor is confident that legal action will follow from access, exchange, or use of EHI related to reproductive health care. “Are at risk” would simply mean that the risk the actor believes might arise as a consequence of the affected access, exchange, or use of EHI is one that could, to the best of the actor's knowledge and understanding, arise under law that is in place at the time the practice(s) that is based on the belief are implemented. Thus, the proposed § 171.206 exception would not apply to practices undertaken based on a hypothetical risk of exposure to legal action, such as one the actor postulates could perhaps become possible if applicable law(s) were to change in the future. Similarly, where an actor may believe a risk exists that someone could potentially be exposed to legal action but does not believe that a particular practice could achieve some reduction in that risk, the § 171.206(a)(1) requirement would not be met by (and therefore the § 171.206 exception would not apply to) that practice.
                    </P>
                    <P>
                        The § 171.206(a) 
                        <E T="03">threshold</E>
                         condition's tailoring requirement (§ 171.206(a)(2)) is intended to further restrict the exception's coverage to practices that are no broader than necessary to reduce the risk of potential exposure to legal action that the actor has a good faith belief could arise from the particular access, exchange or use of the specific EHI.
                    </P>
                    <P>Like similar provisions in other exceptions, this tailoring requirement ensures that the exception would not apply to an actor's practices likely to interfere with access, exchange, or use of all of an individual's EHI when it is only portions of the EHI that the actor believes could create the type of risk recognized by the exception. Where only portion(s) of the EHI an actor has pertaining to one or more patients pose a risk of potentially exposing some person(s) to legal action, the proposed Protecting Care Access Exception would apply only to practices affecting particular access, exchange, or use of the specific portion(s) of the EHI that pose the risk.</P>
                    <P>Data segmentation is important for exchanging sensitive health data (as noted in the ONC Cures Act Final Rule at 85 FR 25705) and for enabling access, exchange, and use of EHI (as noted in the HTI-1 Proposed Rule at 88 FR 23874). We are aware of external efforts to innovate and mature consensus technical standards, and we hope this will foster routine inclusion of increasingly advanced data segmentation capabilities in more EHR systems and other health IT over time.</P>
                    <P>
                        However, we have received public feedback (both prior to and in response to the HTI-1 Proposed Rule request for information on health IT capabilities for data segmentation and user/patient access at 88 FR 23874 through 23875) indicating that there is currently significant variability in health IT products' capabilities to segment data, such as to enable differing levels of access to data based on the user and purpose. We recognize there is a potential that some actors who may wish to withhold specific EHI under the conditions specified in the proposed Protecting Care Access Exception (§ 171.206) may not yet have the technical capability needed to unambiguously segment the EHI for which § 171.206 would apply from other EHI that they could lawfully make available for a particular access, exchange, or use. Therefore, we propose elsewhere in this proposed rule to modify the Infeasibility Exception's 
                        <E T="03">segmentation</E>
                         condition (§ 171.204(a)(2)) to explicitly provide for circumstances where the actor cannot unambiguously segment EHI that may be withheld in accordance with Protecting Care Access Exception (§ 171.206) from the EHI for which this exception is not satisfied. (This and other proposed revisions to § 171.204(a)(2) are discussed in section IV.B.2.A of this proposed rule.)
                    </P>
                    <P>
                        The implementation requirement in subparagraph (a)(3) of the 
                        <E T="03">threshold</E>
                         condition is intended to ensure that practices are applied fairly and consistently while providing flexibility for actors to implement a variety of practices, and to do so through organizational policy or in response to specific situations, as best suits their needs. We propose that any given practice could satisfy this implementation requirement in either of two ways. First, an actor could undertake the practice consistent with an organizational policy that meets the requirements proposed in § 171.206(a)(3)(i). To satisfy the proposed requirement in this first way, the organization's policy would need to identify the connection between the particular access, exchange, or use of the specific EHI with which the practice interferes and the risk of potential exposure to legal action that the actor believes could be created by such access, exchange, or use. The policy would also need to be:
                    </P>
                    <P>• in writing;</P>
                    <P>• based on relevant clinical, technical, or other appropriate expertise;</P>
                    <P>• implemented in a consistent and non-discriminatory manner; and</P>
                    <P>• structured to ensure each practice implemented pursuant to the policy satisfies paragraphs (a)(1) and (a)(2) as well as at least one of the conditions in paragraphs (b) or (c) of § 171.206 that is applicable to the prohibition of the access, exchange, or use of the EHI.</P>
                    <P>In order to ensure each practice implemented pursuant to the policy applies only to the particular access, exchange, or use scenario(s) to which at least one of the conditions in paragraphs (b) or (c) of § 171.206 is applicable, a policy would need to specify the facts and circumstances under which it would apply a practice. Such specifications need not be particularized to individual patients but would need to identify with sufficient clarity for the actor's employees and business associates (or other contractors, as applicable) to accurately apply the practice only to relevant access, exchange, or use scenarios. The types of facts or circumstances the policy might need to specify may vary, but we believe might often include such details as to what EHI (such as what value set(s) within what data element(s)) and to what scenario(s) of access, exchange, or use the policy will apply to a practice.</P>
                    <P>
                        There may be value sets currently available or in development by various parties that may help an actor to identify what EHI within the actor's EHR or other health IT systems indicates care meeting the reproductive health care definition in 45 CFR 160.103. However, we do not propose to limit the application of the exception to any specific value set(s). Because version updates of such value sets, or new value sets, may develop more rapidly than adoption or reference of them in regulations could occur, we believe the intended operation of the exception will be best served by leaving actors flexibility to identify, document in their organizational policy or case-by-case determination(s), and then use whatever value set(s) comport with their belief that a risk of potential exposure to legal action (consistent with the exception's conditions) could be created or increased by sharing specific EHI indicating or (where the 
                        <E T="03">patient protection</E>
                         condition applies) potentially related to reproductive health care.
                    </P>
                    <P>
                        The proposed provision in paragraph (a)(3)(ii) offers actors the second of the two ways to satisfy subparagraph (a)(3): 
                        <PRTPAGE P="63635"/>
                        by making determination(s) on a case-by-case basis. To satisfy paragraph (a)(3)(ii), any case-by-case determination would need to be made in the absence of an organizational policy applicable to the particular situation and be based on facts and circumstances known to, or believed in good faith by, the actor at the time of the determination. A practice implemented based on the determination must also be tailored to reduce the risk of legal action the actor has a good faith belief could result from access, exchange, or use of the EHI. And the practice must be no broader than necessary to reduce the risk of potential exposure to legal action (paragraphs (a)(1) and (a)(2)).
                    </P>
                    <P>Finally, to meet paragraph (a)(3)(ii), the determination made on a case-by-case basis would need to be documented either before or contemporaneous with beginning to engage in any practice(s) based on the determination. The documentation of the determination must identify the connection or relationship between the interference with access, exchange, or use of EHI indicating or related to reproductive health care and the risk of potential exposure to legal action. By identifying the connection or relationship, this documentation would explain what risk the actor believes the practice(s) will mitigate.</P>
                    <P>The proposed § 171.206(a)(3) implementation requirement's optionality would support the actor's interest in having flexibility to address both relatively stable and more dynamic facts and circumstances. Each of the options is intended to balance this interest of the actor with the interests of others, including the actor's current and potential competitors, in ensuring that any information blocking exception does not apply to practices that are not necessary for the specific purpose(s) the exception is designed to serve. The subparagraph (a)(3)(i) organizational policy provision would allow actors to apply relevant expertise available at the time of creating and updating organizational policies to craft a policy that suits their circumstances (such as technological capabilities and staffing and the types of scenarios they have experienced or expect to experience, perhaps with some regularity). The case-by-case determination provision (sub-paragraph (a)(3)(ii)) ensures the proposed exception would be available for all actors across the full array of facts and circumstances they may encounter, including unanticipated ones.</P>
                    <P>
                        We are considering adding to the § 171.206(a) 
                        <E T="03">threshold</E>
                         condition an additional requirement that the actor's practice must not have the effect of increasing any fee for accessing, exchanging, or using EHI that the actor chooses to seek from an individual (as defined in § 171.202(a)) or counsel representing the individual in an action or claim contemplated, filed, or in progress with a Federal agency, in Federal court, or a court in the jurisdiction where care was provided. We propose this requirement in the alternative. This alternative proposal would mean that the proposed exception would not be met by an actor's practice that had such effect even if any fee that the actor chooses to charge for access, exchange, or use of EHI would, after such increase, continue to satisfy the Fees Exception (§ 171.302). We seek comment on this potential additional requirement for an actor's practice to satisfy the proposed 
                        <E T="03">threshold</E>
                         condition (§ 171.206(a)).
                    </P>
                    <HD SOURCE="HD3">c. Patient Protection Condition</HD>
                    <P>
                        The proposed 
                        <E T="03">patient protection</E>
                         condition in paragraph (b) of § 171.206 could be met by practices implemented for the purpose of reducing the patient's risk of potential exposure to legal action (as legal action would be defined in § 171.206(e)). Further narrowing the practices that could satisfy the condition, paragraph (b)(1) would require that the practice affect only specific EHI (the data point or points) that the actor in good faith believes demonstrates, indicates, or would carry a substantial risk of supporting a reasonable inference that the patient has: (1) obtained reproductive health care that was lawful under the circumstances in which such care was provided; (2) inquired about or expressed an interest in seeking reproductive health care; or (3) particular demographic characteristics or health condition(s) or history for which reproductive health care is often sought, obtained, or medically indicated.
                    </P>
                    <P>For purposes of § 171.206, we would interpret “lawful under the circumstances in which it was provided” to mean that when, where, and under relevant circumstances (such as, for health care, the patient's clinical condition and a rendering health care provider's scope of practice) the care was:</P>
                    <P>• protected, required, or authorized by Federal law, including the United States Constitution, in the circumstances under which such health care is provided, regardless of the State in which it is provided; or</P>
                    <P>• not prohibited by Federal law and lawful under the law of the jurisdiction in which it was provided.</P>
                    <P>Where care is not prohibited by Federal law and permitted under the law of the jurisdiction in which it is provided, we would consider the care lawful regardless of whether the same care would, under otherwise identical circumstances, also be unlawful in other circumstances (for instance, if provided in another jurisdiction).</P>
                    <P>
                        The 
                        <E T="03">patient protection</E>
                         condition proposed in § 171.206(b) would provide the actor discretion and flexibility over time to determine which EHI poses a risk of potential exposure to legal action. At the same time, the § 171.206(b)(1) requirement that the practice “affect only the access, exchange, or use of specific electronic health information the actor believes could expose the patient to legal action” because it shows or carries a substantial risk of supporting an inference of one of the things described in subparagraphs (i) through (iii) would preserve the expectation that the actor would share other EHI that the actor does not believe poses such a risk unless another exception applies, or sharing restriction(s) under other law apply, to that other EHI in relevant circumstances.
                    </P>
                    <P>
                        We propose that even when an actor has satisfied the requirements in paragraph (b)(1), the practice would be subject to nullification by the patient if the patient explicitly requests or directs that a particular access, exchange, or use of the specific EHI occur despite any risk(s) the actor has identified to the patient. This requirement (paragraph (b)(2)) is intended to respect patients' autonomy to choose whether and when to share their own EHI. The requirement would prevent the exception from applying where an actor is attempting to substitute their judgment or tolerance of risks to the patient for the patient's own judgment.
                        <SU>249</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>249</SU>
                             The 
                            <E T="03">patient protection</E>
                             condition in § 171.206(b) would apply to practices implemented for the purpose of reducing the patient's risk of potential exposure to legal action (as legal action would be defined in § 171.206(e). The 
                            <E T="03">care access</E>
                             condition in § 171.206(c) would apply to practices an actor implements to reduce potential exposure to legal action based on the mere fact that reproductive health care occurred for persons, other than the person seeking or receiving care, who provide care or are otherwise involved in facilitating the provision or receipt of reproductive health care that is lawful under the circumstances in which it is provided. In some circumstances, an actor's practice might meet both the § 171.206(b) 
                            <E T="03">patient protection</E>
                             and § 171.206(c) 
                            <E T="03">care access</E>
                             conditions simultaneously. But each of these conditions could also apply in circumstances where the other does not. Thus, the proposed exception is intended and designed to apply where either or both of the 
                            <E T="03">patient protection</E>
                             and c
                            <E T="03">are access</E>
                             conditions are met in complement to the § 171.206(a) 
                            <E T="03">threshold</E>
                             condition.
                        </P>
                    </FTNT>
                    <PRTPAGE P="63636"/>
                    <P>
                        We clarify in proposed paragraph (b)(3) that for purposes of the 
                        <E T="03">patient protection</E>
                         condition “patient” means the natural person who is the subject of the electronic health information or another natural person referenced in, or identifiable from, the EHI as a person who has sought or obtained reproductive health care. We propose to also recognize as “patients,” for purposes of this condition, natural persons other than the natural person who is the subject of the EHI because we are aware that in the field there may be times when information about a parent's reproductive health care is included in the EHI of a child. (A child's parent is often identified in or identifiable through the child's EHI.)
                    </P>
                    <P>
                        We note that the 
                        <E T="03">patient protection</E>
                         condition, and generally the exception, are not intended to permit any actor to avoid legal consequences resulting from malpractice or their own wrongdoing. The proposed exception is also not intended to have any effect on any obligation an actor has to comply with disclosure requirements under Federal, State, or Tribal law that applies to the actor. Even where an actor could deny any given access, exchange, or use of EHI for permissible purposes consistent with an information blocking exception, the actor who is a HIPAA covered entity or business associate would still have to comply with the 45 CFR 164.524 individual right of access, and any actor would still have to comply with other valid, applicable law compelling the actor to make the EHI available for permissible purposes.
                        <SU>250</SU>
                        <FTREF/>
                         For example, the actor would still need to comply with applicable legal discovery rules and judicial orders issued by a court of competent jurisdiction. Non-compliance with such other laws could subject the actor to sanctions under those other laws regardless of whether the actor's practice would also be considered information blocking or would instead be covered by an exception set forth in any subpart of 45 CFR part 171.
                    </P>
                    <FTNT>
                        <P>
                            <SU>250</SU>
                             For purposes of the information blocking regulations, “permissible purpose” is defined in 45 CFR 171.102.
                        </P>
                    </FTNT>
                    <P>
                        We are also considering, and propose in the alternative, adding one or more of the following explicit requirements to the 
                        <E T="03">patient protection</E>
                         (§ 171.206(b)), 
                        <E T="03">care access</E>
                         (§ 171.206(c)), or 
                        <E T="03">threshold</E>
                         (§ 171.206(a)) condition(s) so that to be covered by the exception the actor's practice must not:
                    </P>
                    <P>• if undertaken by any actor that is also a HIPAA covered entity or business associate, delay beyond the time allowed under 45 CFR 164.524 or otherwise interfere with any request for access, exchange, or use of EHI that implicates the HIPAA Privacy Rule's individual right of access in a manner or to an extent that would constitute non-compliance with 45 CFR 164.524;</P>
                    <P>• deny the individual (as defined in § 171.202(a)(2)) or an attorney representing the individual access, exchange, or use of EHI for purposes of considering, bringing, or sustaining any claim for benefits under any Federal law or any action against the actor under administrative, civil, or criminal (including discovery and other procedural) law of the jurisdiction in which care indicated by the EHI was provided;</P>
                    <P>• interfere with any use or disclosure of EHI required by subpart C of 45 CFR part 160 as it applies to actions by the Secretary (or by any part of HHS) with respect to ascertaining compliance by covered entities and business associates with, and the enforcement of, applicable provisions of 45 CFR parts 160, 162, and 164; or</P>
                    <P>• prevent any EHI's use by or disclosure to a Federal agency or a State, or Tribal authority in the jurisdiction where health care indicated by the EHI was provided, to the extent such use or disclosure is permitted under 45 CFR parts 160 and 164.</P>
                    <P>Each (or any) of these requirements would function as a limit on the applicability of the exception and mean that practices not meeting the exception for those reasons could constitute information blocking in addition to potentially violating any other law. (Due to the substantial variation across individual actors' circumstances, it would be impossible to maintain in the text of 45 CFR part 171 an accurate, comprehensive catalog of all other laws that could be implicated by an actor's practices otherwise consistent with any exception set forth in subparts B, C, or D of 45 CFR part 171.)</P>
                    <P>We welcome comments on the proposed exception, including whether commenters would recommend we add to the exception (if finalized) any or all of the above potential additional limits on applicability of the proposed Protecting Care Access Exception (§ 171.206) that we propose in the alternative.</P>
                    <HD SOURCE="HD3">d. Care Access Condition</HD>
                    <P>
                        The proposed 
                        <E T="03">care access</E>
                         condition would apply as specified in paragraph (c) of § 171.206 under the “Regulatory Text” heading of this proposed rule. The condition could be met by practices an actor implements to reduce potential exposure to legal action based on the mere fact that reproductive health care occurred for persons, other than the person seeking or receiving care, who provide care or are otherwise involved in facilitating reproductive health care that is lawful under the circumstances in which it is provided. Such persons would include licensed health care professionals, other health care providers, and other persons involved in facilitating care that is lawful under the circumstances in which it is provided. Such persons would include persons (friends, family, community caregivers, and others) who help patients find, get to the site of or home from, and afford care. For purposes of the 
                        <E T="03">care access</E>
                         condition in § 171.206(c) and § 171.206(b)(1)(i) (within the 
                        <E T="03">patient protection</E>
                         condition), the reproductive health care must be “lawful under the circumstances in which it is provided” as explained above in section IV.B.3.c of this proposed rule.
                    </P>
                    <P>
                        To satisfy the 
                        <E T="03">care access</E>
                         condition in paragraph (c) of § 171.206 as proposed, the practice must affect only access, exchange, or use of specific EHI (one or more data points) that the actor believes could potentially expose a care provider(s) or facilitator(s) to legal action because that EHI shows or would carry a substantial risk of supporting a reasonable inference that such person(s) are currently providing or facilitating, have provided or facilitated, or both, reproductive health care that is (or was) lawful under the circumstances in which it is (or was) provided.
                        <SU>251</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>251</SU>
                             The 
                            <E T="03">patient protection</E>
                             condition in § 171.206(b) would apply to practices implemented for the purpose of reducing the patient's risk of potential exposure to legal action (as legal action would be defined in § 171.206(e). The 
                            <E T="03">care access</E>
                             condition in § 171.206(c) would apply to practices an actor implements to reduce potential exposure to legal action based on the mere fact that reproductive health care occurred for persons, other than the person seeking or receiving care, who provide care or are otherwise involved in facilitating the provision or receipt of reproductive health care that is lawful under the circumstances in which it is provided. In some circumstances, an actor's practice might meet both the § 171.206(b) 
                            <E T="03">patient protection</E>
                             and § 171.206(c) 
                            <E T="03">care access</E>
                             conditions simultaneously. But each of these conditions could also apply in circumstances where the other does not. Thus, the proposed exception is intended and designed to apply where either or both of the 
                            <E T="03">patient protection</E>
                             and 
                            <E T="03">care access</E>
                             conditions are met in complement to the § 171.206(a) 
                            <E T="03">threshold</E>
                             condition.
                        </P>
                    </FTNT>
                    <P>
                        We propose this requirement in order to ensure the § 171.206(c) 
                        <E T="03">care access</E>
                         condition would not apply to an actor's practice affecting access, exchange, or use of EHI that the actor does not believe could create a risk of potential exposure to legal action based on the mere fact that reproductive health care was provided or facilitated. Actors will often have additional EHI that applicable law would also permit them 
                        <PRTPAGE P="63637"/>
                        to make available for permissible purposes, which could include information relevant to the safety, continuity, and quality of care, such as a patient's chronic condition(s) or a medically confirmed allergy to a substance that does not indicate or suggest reproductive health care has, or may have, occurred (and thus poses no risk of exposure to legal action as defined in § 171.206(e)). To the extent the actor has such other EHI that the actor can (both legally and technically) make available for any and all permissible purposes, we would expect the actor to do so. We recognize that in some circumstances the actor may need to make such other EHI available in an alternative manner rather than the manner requested by the requestor. (We use “manner requested” and “alternative manner” here in a sense consistent with paragraphs (a) and (b), respectively, of the Manner Exception as currently codified in § 171.301.)
                    </P>
                    <P>
                        We propose that when an actor's practice satisfies the 
                        <E T="03">threshold</E>
                         condition in § 171.206(a) and meets all the requirements of the 
                        <E T="03">care access</E>
                         condition in § 171.206(c), the actor's practice will not constitute information blocking. As with any of the existing exceptions, the proposed Protecting Care Access Exception would not supersede or override any other valid Federal, State, or Tribal laws that compel production of EHI for purposes of legal proceedings or that compel other disclosures in relevant circumstances. Therefore, actors and other interested persons will want to remember that satisfying an exception set forth in 45 CFR part 171 does not prevent other law that operates independently from the 45 CFR part 171 from potentially compelling an actor to provide access, exchange, or use of EHI in manners or for purposes the actor, or an individual, might prefer the EHI not be accessed, exchanged, or used. As actors are likely already aware, conduct that is not considered “information blocking” under 45 CFR part 171, whether on the basis of satisfying an exception or on the basis of not meeting an element of the definition of “information blocking” in the information blocking statute (42 U.S.C. 300jj-52) may nevertheless violate, and may subject the actor to consequences authorized by, laws separate from and operating independently of the information blocking statute and 45 CFR part 171.
                    </P>
                    <P>
                        The 
                        <E T="03">care access</E>
                         condition would apply where the risk of potential exposure to legal action is specific to the mere fact that reproductive health care (that was lawful under the circumstances in which it was provided) was provided or facilitated. The 
                        <E T="03">care access</E>
                         condition would not be met where the risk of potential exposure to legal action is based on care having been provided in circumstances where the care was not lawful. (We refer readers again to our explanation, in Section IV.B.3.c of this proposed rule, of how we would interpret “lawful under the circumstances” in which care was provided in context of the proposed § 171.206.)
                    </P>
                    <P>The proposed exception would not apply to a practice that precludes the patient or an attorney representing the patient from obtaining access, exchange, or use of the patient's EHI for purposes of filing a benefit claim or a complaint against the actor with any agency of the U.S. Government. It would be unreasonable for an actor to withhold from a patient or a patient's attorney EHI that they need or seek to use in support of a claim for a benefit that is filed with any agency of the U.S. Government. It would also be unreasonable for the actor to attempt to withhold EHI access, exchange, or use to impede the patient or the patient's attorney filing, or the U.S. Government investigating, any complaint against the actor that the patient or the patient's attorney may file with any agency of the U.S. Government. Patients and their attorneys should have easy access to necessary information for considering, filing, or maintaining or pursuing such claims or complaints.</P>
                    <P>
                        As we have noted several times in this proposed rule, an actor that is also required to comply with the HIPAA Privacy Rule must comply with the individual right of access as codified in 45 CFR 164.524 regardless of whether the actor may be able to satisfy any existing or proposed exceptions to the § 171.103 definition of “information blocking.” To ensure actors remain aware of this fact, we propose as the first of several (non-exclusive) alternatives, to include in the proposed 
                        <E T="03">care access</E>
                         condition (§ 171.206(c)) an additional explicit restriction of the condition to practices that do not violate 45 CFR 164.524. We might finalize this additional requirement even if we do not finalize any of the other additional requirements that we propose to potentially apply to the Protecting Care Access Exception as a whole or to the proposed 
                        <E T="03">patient protection</E>
                         condition (§ 171.206(b)) (as discussed in section IV.B.3.b, above).
                    </P>
                    <P>
                        The first requirement we propose in the alternative specific to the 
                        <E T="03">care access</E>
                         condition would provide for the 
                        <E T="03">care access</E>
                         condition (§ 171.206(c)) to be met by practices that could interfere with an individual's access to EHI only to the extent that the interference could otherwise implicate the “information blocking” definition in § 171.103 without also constituting non-compliance with 45 CFR 164.524 where 45 CFR 164.524 also applies. For example, under this first proposed potential added restriction on applicability of § 171.206(c), a delay of an individual's access, exchange, or use of EHI that would rise to the level of an “interference” for purposes of the “information blocking” definition in § 171.103 that satisfied all other requirements of § 171.206(a) and (c) would be covered by the § 171.206 exception only to the extent the delay of the individual's (or their personal representative's) access to EHI did not exceed the maximum time permitted, in the specific circumstances, for fulfillment of access to PHI under 45 CFR 164.524. (Coverage of an exception would be irrelevant for a delay not rising to the level of an “interference” because § 171.103 focuses on practices not required by law that are likely to “interfere with” access, exchange, or use of EHI.) This proposed restriction to practices not violating § 164.524 would also mean § 171.206 would apply where an actor's interference involved offering fewer manners of access, exchange, or use than would be feasible for the actor to support, but only to the extent that the actor's limiting the manners in which EHI is made available would not constitute a violation under 45 CFR 164.524. We welcome comment on this first additional potential limitation on the applicability of the proposed exception.
                    </P>
                    <P>
                        We propose as a second (again, non-exclusive) alternative to include in the proposed 
                        <E T="03">care access</E>
                         condition (§ 171.206(c)) an additional requirement that would be applicable specifically if an actor chooses to engage in a practice of delaying fulfillment of requests for EHI access, exchange, or use by individuals (as defined in § 171.202(a)(2)) because the actor wants to provide, in a non-discriminatory manner, information to the individual relevant to the actor's good faith belief that a risk of potential exposure to legal action could be created by the individual's choice of how to receive their EHI or to whom the individual wishes to direct their EHI. For example, an actor that is also a HIPAA covered entity would, under § 164.524, be required to fulfill an individual's request for access to PHI or to transmit to a third party an electronic copy of the individual's PHI in an EHR within the time period required under § 164.524. 
                        <PRTPAGE P="63638"/>
                        Where the § 171.206 exception would apply and the third party is not a covered entity or business associate, the actor may wish to first provide the individual with information (that is, to the best of the actor's knowledge and belief, accurate and factual) about the HIPAA Privacy, Security, and Breach Notification Rules and differences in their applicability to EHI when it is not held by a HIPAA covered entity or business associate in comparison to when it is. Similarly, an actor might wish to communicate such information to an individual before enabling access, exchange, or use of EHI for a health care provider that is not a HIPAA covered entity or business associate. The actor might, for example, be concerned that the individual may not have previously obtained or been provided basic information about how the applicability of the HIPAA Privacy Rule to information held by or for a provider that is not a HIPAA covered entity may differ from the rule's application to the same information when it is held by or for entities regulated under HIPAA. The actor may wish to provide the individual such information so that the individual would have a fair opportunity to consider the possible privacy risks. In such situations, the actor may be concerned about potential information blocking implications of the delay that is necessary to provide the individual with information. Or the actor may be concerned with the delay that results when an individual (or their personal representative) is considering the information before confirming they want the actor to proceed with enabling the application the individual (or their personal representative) has chosen to receive the EHI of which the individual is a subject. Specifically, the actor may be concerned these delays could rise to the level of an “interference” and, therefore, implicate the information blocking definition even if the time required is less than the maximum time permitted to fulfill PHI access under 45 CFR 164.524 in the relevant circumstances.
                    </P>
                    <P>Therefore, we are considering the second proposed additional a requirement for § 171.206. This second potential additional requirement would apply where an actor's practice delays making EHI available upon individual request or directive in order to provide individuals with non-biased general information about relevant laws or about the actor's belief that is consistent with § 171.206(a)(1)(i), the delay must be of no longer duration than is reasonably necessary to provide to the individual two things:</P>
                    <P>(1) honest information that is provided in a non-discriminatory manner and that is relevant to the actor's belief that a risk of potential exposure to legal action could be created by the particular access, exchange, and use of what specific EHI, such as general information about privacy laws or other laws that the actor believes may be relevant; and</P>
                    <P>(2) a reasonable opportunity to consider the information and seek additional information from other sources if the individual would like, before the individual is asked to either confirm or revise any specifics of their request for access, exchange, or use of their EHI.</P>
                    <P>
                        Under this alternative proposal specific to delaying a response to a right of access request (including the right to direct a HIPAA covered entity to transmit to a third party an electronic copy of the individual's PHI in an EHR), delays longer than reasonably necessary to provide the individual with information relevant to the actor's belief that is consistent with § 171.206(a)(1) and allow the individual to consider the actor's information and seek information from additional source(s) (if the individual desires) would not satisfy the § 171.206(c) 
                        <E T="03">care access</E>
                         condition. This proposed restriction that is specific to delays for the purpose of informing individuals of an actor's belief that sharing specific EHI could create risk of potential exposure to legal action could be implemented regardless of whether we also implement a requirement that, for the 
                        <E T="03">care access</E>
                         condition or for the 
                        <E T="03">threshold</E>
                         condition to be met by an actor's practice, the practice must not constitute a violation of § 164.524. This potential additional requirement would limit the applicability of the condition in scenarios where an actor might choose to engage in delay to provide individuals with information about potential privacy consideration, but should not be construed as creating an affirmative requirement for any actor to delay fulfillment of individual access requests to provide individuals with information about potential privacy implications of the individual's request. We reiterate that information blocking exceptions are voluntary.
                    </P>
                    <P>We reiterate that even in scenarios where an actor's denial of access, exchange, or use of EHI might not be “information blocking” because it satisfies an exception under and for purposes of part 171, an actor that is a HIPAA covered entity or business associate will still need to comply with 45 CFR 164.524 (individual right of access). (This is true of the exceptions codified in subparts B, C, and D of 45 CFR part 171 as of the date of publication of this proposed rule and would also be true of the new exceptions proposed in this rule in the event any of them are finalized.)</P>
                    <P>The additional requirement(s) we are considering, and as noted above propose in the alternative, would seek to more finely tune the exception's balance of the interests of actors and patients in protecting reproductive health care availability by mitigating legal risks for the people who provide that care, and for the people who facilitate the provision of such care, with the interests of individuals in being able to access, exchange, and use all of their EHI however and whenever they want, and to share all of their EHI however and with whomever they choose, at no cost for “electronic access” as defined in § 171.302(d). We seek comment on these proposals.</P>
                    <HD SOURCE="HD3">e. Clarifying Provisions: Presumption and Definition of “Legal Action”</HD>
                    <P>For purposes of determining whether an actor's practice meets paragraph § 171.206(b)(1)(i) or § 171.206(c), we propose in § 171.206(d) that care furnished by someone other than the actor would be presumed to be lawful unless the actor has actual knowledge that the care was not lawful under the circumstances in which it was provided. The presumption provision proposed in § 171.206(d) is similar to the presumption provision finalized (in 45 CFR 164.502(a)(5)(iii)(C)) by the 2024 HIPAA Privacy Rule, but is necessarily different because of differences in how the prohibition at 45 CFR 164.502(a)(5)(iii)(A) operates and how the proposed Protecting Care Access Exception (§ 171.206) is intended to operate.</P>
                    <P>First, the proposed Protecting Care Access Exception (§ 171.206) would be voluntary. It would offer those actors who may wish to engage in practices likely to interfere with EHI access, exchange, or use under the exception's conditions certainty that practices satisfying the exception will not be considered “information blocking.” Nothing in § 171.206 is intended to create an affirmative obligation for any actor to evaluate whether the Protecting Care Access Exception might apply to any access, exchange, or use of EHI for permissible purposes.</P>
                    <P>
                        Second, the proposed Protecting Care Access Exception (§ 171.206) is based on statutory authority found in section 3022 of PHSA to identify reasonable and necessary activities that do not constitute information blocking for purposes of the PHSA 3022 definition of the term. We do not propose that 
                        <PRTPAGE P="63639"/>
                        anything in § 171.206 would operate to override an actor's obligation to comply with another (applicable) law that requires the actor to make EHI available for any permissible purpose. Thus, an actor may still be compelled to disclose EHI in compliance with such other law even where the exception might mean an actor's failure to comply with such other law would not be considered “information blocking” under 45 CFR part 171 or PHSA 3022. (The exception would not be relevant where an actor is also a HIPAA covered entity or business associate would be required to comply with the prohibition at 45 CFR 164.502(a)(5)(iii) because a HIPAA covered entity's or business associate's practice of refusing to make a use or disclosure of PHI prohibited by the HIPAA Privacy Rule is “required by law” and therefore not information blocking to begin with.)
                    </P>
                    <P>Finally, a policy goal of the proposed Protecting Care Access Exception is that it be easy for any actor to confidently and efficiently meet the conditions of the proposed exception. One way the exception's structure supports this goal is by providing (in § 171.206(a)(3)(i)) for the actor to implement practices per organizational policies that address particular types of EHI sharing scenarios where the actor believes the risk of potential exposure to legal action could be created even if the actor has not yet received a request for EHI for the activities specified in 45 CFR 164.502(a)(5)(iii)(A) or any of the purposes specified in 45 CFR 164.512(d), (e), (f), or (g)(1) for which the attestations specified in 45 CFR 164.509 would be required as a precondition for disclosing PHI potentially related to reproductive health care to be permitted under the 2024 HIPAA Privacy Rule.</P>
                    <P>
                        As noted elsewhere, an actor's practice satisfying the new exception would mean the practice will not be considered information blocking. To the extent that EHI indicates or potentially relates to reproductive health care that was not lawful under the specific circumstances in which it was provided, we presume that the legal authority compelling disclosure of EHI for such purposes would have its own enforcement provisions independent of the penalties and disincentives authorized by PHSA 3022 for an actor determined by the HHS OIG to have committed information blocking. Because exception would not exempt the actor from their obligation to comply with such other law, we do not believe it is necessary to preserve the potential for information blocking penalties to apply in addition to any consequences that might attach under such other law to an actor's non-compliance with that law. On the other hand, we believe it is important to ensure that concern about information blocking consequences would not prevent the actor from, for example, delaying fulfillment of a demand for EHI in order to review factual information supplied by the requestor and determine whether that information “demonstrates a substantial factual basis” (as stated in 45 CFR 164. 502(a)(5)(iii)(C)(2)) and, by extension, whether the 2024 HIPAA Privacy Rule or applicable State law permits, preempts, or conflicts with the law the requestor indicates compels the actor to make the EHI available to the requestor.
                        <SU>252</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>252</SU>
                             We remind readers that the currently codified “pre-condition not satisfied” sub-exception of the Privacy Exception outlines a framework for actors to follow so that the actors' practices of not fulfilling requests to access, exchange, or use EHI would not constitute information blocking when one or more preconditions has not been satisfied for the access, exchange, or use to be permitted under applicable Federal and State, or Tribal laws. Please 
                            <E T="03">see</E>
                             § 171.202(b) and discussion in HTI-1 final rule (at 89 FR 1351 through 1354) of how information blocking exception work in concert with the HIPAA Rules and other privacy laws to support health information privacy.
                        </P>
                    </FTNT>
                    <P>We are, moreover, concerned that tying the proposed § 171.206(d) presumption provision to the requestor not supplying information demonstrating a substantial factual basis that the reproductive health care was not lawful under the specific circumstances in which it was provided would make the proposed Protecting Care Access Exception (§ 171.206) more difficult for actors to use and therefore could discourage actors from using it. We are concerned this difficulty could discourage use of the exception particularly by those actors—such as small and safety net health care providers or non-profit health information networks who serve them—who may have limited ability to divert resources to these types of legal analyses, especially in circumstances where this exception is intended to apply but the request for EHI access, exchange, or use may not be coming from a law enforcement entity and the access, exchange, or use of EHI sought may not be for a law enforcement purpose.</P>
                    <P>We propose in the alternative to add to § 171.206(d), if finalized, a provision that parallels the provision in 45 CFR 164.502(a)(5)(iii)(C)(2) and that would prevent the § 171.206(d) presumption from applying where factual information supplied by the person requesting access, exchange, or use of EHI demonstrates a substantial factual basis that the reproductive health care was not lawful under the specific circumstances in which it was provided. We welcome comments on this alternative proposal. We are particularly interested in whether and why actors, patients, and other interested parties may believe § 171.206(d) would strike a better balance between actors' interests in a simpler, more easily usable exception and requestors' interests in obtaining EHI for permissible purposes with or without the additional limit on application of the presumption provision.</P>
                    <P>
                        We propose in § 171.206(e) to define “legal action” for purposes of the Protecting Care Access Exception. Under the proposed definition, “legal action” would include any of the following when initiated or pursued against any person for the mere act of seeking, obtaining, providing, or facilitating reproductive health care: (1) civil, criminal, or administrative investigation; (2) a civil or criminal action brought in a court to impose criminal, civil, or administrative liability; or (3) an administrative action or proceeding against any person. We emphasize that the proposed Protecting Care Access Exception would apply where an actor's practice meets the § 171.206(a) 
                        <E T="03">threshold</E>
                         condition and at least one of the other two conditions in the exception, none of which would require the actor to quantify a degree, amount, or probability of the risk of potential exposure to legal action the actor believes in good faith exists and could be reduced by the practice to which § 171.206 applies.
                    </P>
                    <P>We welcome comment on all aspects of the proposal for a new Protecting Care Access Exception to the information blocking definition.</P>
                    <HD SOURCE="HD3">4. Requestor Preferences Exception</HD>
                    <P>We propose a new exception, “Requestor Preferences,” in § 171.304 to offer actors certainty that, under the conditions specified in this exception, it would not be considered “information blocking” to honor a requestor's preferences expressed or confirmed in writing for: (1) limitations on the scope of EHI made available to the requestor; (2) the conditions under which EHI is made available to the requestor; and (3) the timing of when EHI is made available to the requestor for access, exchange, or use.</P>
                    <P>
                        Since publication of the ONC Cures Act Final Rule, actors have indicated a preference for greater certainty as to the conditions under which they would not be committing information blocking if they were to honor certain preferences expressed by a requestor seeking lawful 
                        <PRTPAGE P="63640"/>
                        access, exchange, or use of EHI. In some instances, this preference might be that some type(s) of new EHI are not made available as quickly as would be technically feasible or that a more limited scope of EHI is made available than would be permitted (or required) under applicable law based on whose EHI the requestor seeks and for what purpose(s). For example, actors have indicated that they are uncertain of the scenarios when honoring an individual's request for delay of EHI availability to the individual in the patient portal would not be information blocking. Actors have also indicated that they are unable to honor a health care provider's expressed preference to receive only some of the EHI that an actor has and could disclose to the provider under applicable law, because the actor is uncertain whether honoring the health care provider's preference would be considered information blocking. The proposed exception (new § 171.304) would address these concerns by providing certainty of the conditions under which we would not consider an actor to engage in information blocking when the actor honors a requestor's preference to: (1) receive only a subset of EHI (limitation on scope of EHI), (2) have the EHI be available to the requestor only under specific timing or other conditions, or (3) any combination of such preferences.
                    </P>
                    <P>
                        We recognize that, sometimes, a requestor who seeks access, exchange, or use of EHI may prefer to have less EHI available to the requestor than an actor has and would be permitted to make available under the HIPAA Privacy Rule (and any other applicable law(s) restricting uses and disclosures of an individual's health information to protect the individual's privacy). We also recognize that sometimes a requestor may not want particular EHI to be available to the requestor immediately, perhaps preferring the EHI not be available until a certain period of time has elapsed or until certain conditions are met. For example, an individual who uses a patient portal or app to access EHI of which they are the subject may not want certain test results to be available in that patient portal or app for a certain number of hours or until the next business day (timing preference). Similarly, an individual may not want the results of certain diagnostic tests performed on the individual to be available to the individual in a patient portal or app until the doctor who ordered the test(s) has seen the results or until a doctor, nurse, or other health care professional is available who can explain what the results mean (conditions for making EHI available preference). For a provider-to-provider example, a primary-care clinician office (requestor) may ask that for laboratory tests done more than once during a patient's stay at a hospital, the hospital (actor) only send the clinician office the results from the last time each test was done (scope of EHI preference), and only send that EHI to the clinician office upon the patient's discharge from the hospital stay (a preference for the conditions under which EHI becomes available). As another provider-to-provider example, a health care provider (requestor) might ask another health care provider (actor) to not send all of the medication history the responding actor has for a patient that the actor is legally permitted to share with the requesting health care provider. The requestor might ask the responding actor to send instead only the patient's current medications and known allergies. The proposed exception (to be codified in § 171.304) would address all of these examples and a variety of other situations. The proposed exception (§ 171.304) has four separate conditions: (a) 
                        <E T="03">request;</E>
                         (b) 
                        <E T="03">implementation,</E>
                         (c) 
                        <E T="03">transparency;</E>
                         and (d) 
                        <E T="03">reduction or removal.</E>
                         In order for an actor's practice(s) to satisfy the proposed Requestor Preferences Exception (§ 171.304), the practice(s) would have to meet all four of the conditions at all relevant times.
                    </P>
                    <P>
                        The 
                        <E T="03">request</E>
                         condition (paragraph (a)) of this proposed new exception would require that the requestor express their preferences in writing without the actor improperly encouraging or inducing the requestor to ask for restrictions on the scope of EHI that would be available to the requestor, the conditions for which the EHI would be available, or timing of when EHI would be available to the requestor. This condition is similar to our approach under the Privacy Exception (§ 171.202) for obtaining a patient's consent under sub-exception (b), which cannot be satisfied if the actor improperly encourages or induces the individual to withhold consent or authorization. It is also similar to a provision of the Privacy Exception's sub-exception (e), which can be satisfied only if the individual requests that the actor not provide such access, exchange, or use of EHI without any improper encouragement or inducement of the request by the actor. In addition to disqualifying an actor's practices in response to such requests from application of the proposed Requestor Preferences Exception, we remind actors that any improper inducement of a patient's or other person's request for delay or other restrictions on a requestor's access to EHI is a practice that, on its own, could constitute an interference that implicates the information blocking definition.
                    </P>
                    <P>
                        To reiterate, the 
                        <E T="03">request</E>
                         condition (§ 171.304(a)) requires the requestor to document in writing their preference (or ask) for tailoring of their access, exchange, or use of EHI. This requirement is intended to guard against the inappropriate citation of the exception to retroactively “justify” the actor's limitation of a requestor's access, exchange, and use of EHI to suit the 
                        <E T="03">actor's</E>
                         preferences. The documentation requirement parallels a similar requirement of the Privacy Exception sub-exception (§ 171.202(e)) applicable to honoring individuals' requests to restrict other people's access, exchange, or use of their EHI.
                        <SU>253</SU>
                        <FTREF/>
                         Subparagraphs (a)(1), (2), and (3) of the proposed § 171.304 
                        <E T="03">request</E>
                         condition also specify, as discussed above, the three types of preferences that the exception would cover.
                    </P>
                    <FTNT>
                        <P>
                            <SU>253</SU>
                             Although we are proposing revision to § 171.202(e) in this rule (
                            <E T="03">see</E>
                             section IV.B.1.c of this preamble), we do not propose any change to the documentation requirement of the § 171.202(e) sub-exception. (The § 171.202(e) documentation requirement was discussed in the ONC Cures Act Final Rule; 
                            <E T="03">see</E>
                             85 FR 25642 at 25858.)
                        </P>
                    </FTNT>
                    <P>
                        The 
                        <E T="03">implementation</E>
                         condition (§ 171.304(b)) would ensure that an actor's practice of limiting the scope of EHI, conditions or timing of EHI availability to the requestor, or any combination of such limitations a requestor may ask for, are “tailored” to the specific request. In this condition, “tailored to the specific request” means the practice is no broader than necessary to do, and in fact does, what the requestor asked for in writing. The § 171.304(b) 
                        <E T="03">implementation</E>
                         condition would also require (see subparagraph (2)) that the request be implemented in a consistent and non-discriminatory manner. This requirement parallels similar requirements in existing exceptions, such as the Preventing Harm Exception (§ 171.201(f)(1)(iii)), Privacy Exception (§ 171.202(b)(1), (c)(3) and (3)), and the Security Exception (§ 171.203(c)). For purposes of § 171.304, discriminatory implementation practices would include, for example, the actor moving more slowly to modify or remove tailoring restrictions (see proposed condition (d)) from access, exchange, or use of EHI based on whether the requestor is a business competitor of the actor or if the requestor's access, exchange, or use of EHI is likely to facilitate competition with the actor. As innovation in biomedical informatics 
                        <PRTPAGE P="63641"/>
                        and health IT advances, we anticipate that the EHI a requestor needs or wants to inform decisions related to seeking or accepting healthcare, or for public health activities or providing or paying for healthcare may change. Therefore, a requestor's preferences for restrictions on the amount of EHI or the conditions or timing of EHI availability to the requestor (or any combination of these) may well change over time. The requirement that the actor's practice be consistent and non-discriminatory is intended, for example, to ensure the exception will not apply to practices that are implemented in a manner that disadvantages competitors, potential competitors, or persons whose access, exchange, or use of EHI may facilitate competition with the actor in comparison to persons who are affiliates or whose access, exchange, or use of EHI would not be expected to facilitate competition with the actor.
                    </P>
                    <P>
                        The 
                        <E T="03">transparency</E>
                         condition (§ 171.304(c)) is intended to mitigate a risk of a specific unintended consequence of creating an exception that explicitly applies to an actor's choosing to agree to a requestor's ask that EHI availability to the requestor be tailored to the requestor's preferences. For example, to the surprise of the requestor, the tailoring of EHI ended up being more or less restrictive than what the requestor thought they agreed to. The risk of surprise to the requestor may arise either when a requestor first asks for tailoring or when an actor may no longer be able to maintain certain tailoring that they have previously agreed to implement in response to a requestor's ask. To mitigate the risk of surprise to a requestor, it is important for a requestor who has asked for tailoring to be informed of what the actor can and will do, or cannot or will not continue to do. To meet the 
                        <E T="03">transparency</E>
                         condition (§ 171.304(c)), an actor would be required to provide, in plain language, whether verbally or in writing, at least the explanation and notification described in the proposed § 171.304(c)(1) and (2) and to document in writing any explanation or notice that is not made in writing.
                    </P>
                    <P>
                        Meeting the 
                        <E T="03">transparency</E>
                         condition (§ 171.304(c)) would not require a contract or other formal agreement between actors and requestors. We also are not suggesting that we believe an actor's agreement to tailor when, how much, or under what conditions EHI becomes available to any given requestor should be treated as establishing a contract or binding agreement.
                    </P>
                    <P>
                        To meet the requirement in subparagraph (1) of § 171.304(c), an actor would be required to explain to the requestor what they can and will do to tailor EHI availability to the requestor. Meeting subparagraph (2) of § 171.304(c) would require an actor who experiences a change in operational status or technical capabilities affecting the actor's ability to maintain tailoring to make “reasonable efforts” to promptly notify each requestor for whom the actor had implemented affected tailoring. We have used the “reasonable efforts” standard in the existing 
                        <E T="03">precondition not satisfied</E>
                         sub-exception of the Privacy Exception (see § 171.202(b)(2)(i)). As we stated in the ONC Cures Act Final Rule preamble discussion of the finalized § 171.202(b), a “reasonable efforts” standard aligns with the case-by-case approach that is captured in the statutory information blocking provision (see 85 FR 25852). Similar to the “reasonable efforts” standard in § 171.202(b)(2)(i), the “reasonable efforts” standard in the proposed § 171.304(c)(2) would be met if the actor used reasonable efforts within its control to promptly provide the requestor with notice of the change in the actor's ability or willingness to continue applying the tailoring of EHI availability to the requestor that the requestor had requested, and the actor had implemented or agreed to implement. (We refer those who would like to read more about the “reasonable efforts” standard in context of the existing § 171.202(b)(2)(i) to the preamble discussion of the finalized § 171.202(b)(2)(i) at 85 FR 25852).
                    </P>
                    <P>
                        “Plain language” is the standard proposed in § 171.304(c) for required explanations and notices rather than “plain writing” because we intend for the § 171.304(c) 
                        <E T="03">transparency</E>
                         condition as a whole to accommodate various methods of communication that are efficient and effective for both the actor who wants to satisfy the exception and the requestor who asks for tailoring. However, regardless of whether the actor and requestor communicate verbally or in writing, plain language would use terminology familiar to the requestor and make it easy for the requestor to understand what tailoring of their EHI access, exchange, or use the requestor can expect to be implemented or to have changed.
                        <SU>254</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>254</SU>
                             If an actor and a particular requestor do not both have at least limited working proficiency in any one language, the actor may need to employ a translator (whether human or an appropriate software application) to achieve communication with the requestor.
                        </P>
                    </FTNT>
                    <P>
                        To meet the 
                        <E T="03">transparency</E>
                         condition, subparagraph (c)(3) specifies that the actor must contemporaneously document in writing any required explanation or notice that is not provided to the requestor in writing. This requirement, like the use of “plain language” rather than “plain writing” as a standard for the explanations and notices, leaves flexibility for actors to communicate with requestors in writing, verbally, or in other ways that are efficient and effective for both the actor and requestor or otherwise mutually agreeable to them. Contemporaneous written documentation of explanations and notices not provided (initially made or later confirmed) to the requestor in writing would enable the actor to demonstrate what explanation or notice they provided and when. Contemporaneous written records of notices made or attempted would also be relevant, where notice fails to reach the requestor or the requestor does not recall details of the notice, to the actor's demonstration of the efforts the actor made to provide notice consistent with § 171.304(c)(2).
                    </P>
                    <P>
                        The 
                        <E T="03">reduction or removal</E>
                         condition (§ 171.304(d)) recognizes that a requestor's tailoring preferences may change over time and requires that an actor's tailoring practice accommodate such changes in requestor preferences. For the actor's practices restricting a requestor's access, exchange, or use of EHI based on the requestor's request to remain covered by this proposed exception when the requestor asks for reduction or removal of restrictions, the 
                        <E T="03">reduction or removal</E>
                         condition (§ 171.304(d)) would require the actor to act promptly as feasible on that request.
                    </P>
                    <P>
                        We do not propose to set a specific timeframe within which an actor would need to act on requests to reduce or remove restrictions upon receipt of any such request from the requestor. Rather, to satisfy the 
                        <E T="03">reduction or removal</E>
                         condition, the actor would need to act as promptly as feasible upon receiving such a request. Basing this requirement on what is feasible for the actor allows for consideration of the specific facts and circumstances under which the actor received the request. We believe this is preferable to setting a single fixed timeframe due to the considerable variation in actors' technical capabilities and operational circumstances at any given point in time. However, we recognize that actors and individuals may find some value in consistent maximum timeframe expectations for acting on a requestor's ask for removal or reduction of previously requested restrictions on their access, exchange, or use of EHI in individual access scenarios. (By “individual access scenarios,” we mean here those where the requestor is either: (a) the individual 
                        <PRTPAGE P="63642"/>
                        who is the subject of the EHI in question; or (b) their legal representative, including, but not limited to, personal representatives treated as the individual consistent with 45 CFR 164.502(g)). Therefore, we are considering specifying in § 171.304(d) that the maximum time any actor would have to reduce or remove the tailoring in any individual access scenario would be the time within which a HIPAA covered entity must provide an individual (as defined in 45 CFR 160.103) or their personal representative (see 45 CFR 164.524(g)) access to PHI in the designated record set under 45 CFR 164.524. Under this alternative proposal, the “as promptly as feasible” standard would apply to all other requestor scenarios without a specified maximum limit on the time an actor could take; but meeting the proposed § 171.304(d) 
                        <E T="03">reduction or removal</E>
                         condition in individual access scenarios would require the actor to reduce or remove restrictions in response to the requestor's request as promptly as feasible but in no case later than the maximum time permitted to fulfill individual access requests under 45 CFR 164.524. (This is an alternative proposal that is not reflected in the draft of § 171.304 in the “Regulatory Text” section of this proposed rule.) This alternative proposal for § 171.304(d) requirements would apply to individual access scenarios regardless of whether 45 CFR 164.524 would, in any given scenario, be implicated (
                        <E T="03">e.g.,</E>
                         even if the actor were not a HIPAA covered entity or business associate).
                    </P>
                    <P>
                        This alternative proposed timeliness requirement for the § 171.304(d) 
                        <E T="03">reduction or removal</E>
                         condition specific to individual access scenarios would establish, by cross-reference to 45 CFR 164.524, that the maximum time the actor would have for acting on a request to reduce or remove restrictions would be the same timeframe within which a HIPAA covered entity must fulfill individual access under 45 CFR 164.524. For purposes of the § 171.304 exception under this alternative proposal, the time for responding to a request for reduction or removal of EHI access, exchange, or use tailoring in individual access scenarios would start on the date on which the actor receives the individual's (or their legal representative's) request for reduction or removal of tailoring. We would craft this additional requirement in this manner specifically so that, in the event the 45 CFR 164.524 timeliness standard were to change in the future (
                        <E T="03">see,</E>
                         for example, the proposal to modify that standard at 86 FR 6459 and 6535), the § 171.304(d) condition would apply the same timeframe in effect for 45 CFR 164.524 at the point in time when an individual who is the subject of the EHI (or their legal representative) requested removal or reduction of restrictions on the individual's (or the legal representative's) EHI access. Such requests are, effectively, the requestor requesting their EHI be made available more promptly or completely than they had previously requested it be available to them. For clarity, once the reduction or removal of tailoring is complete for purposes of this proposed exception, all future requests for access, exchange, or use of EHI previously affected by the reduced or removed tailoring could implicate the interference and information blocking definition particularly §§ 171.103 and 171.104 (new proposed section).
                    </P>
                    <P>
                        If we finalize the proposed § 171.304 exception, with or without any explicit cross-reference to 45 CFR 164.524, this exception would operate as do all other 45 CFR part 171 exceptions: independently from the HIPAA Privacy Rule. We reiterate that an actor who is also a HIPAA covered entity or business associate 
                        <E T="03">must</E>
                         comply with the HIPAA Privacy Rule's requirements implicated in any circumstances or scenario, including without limitation the individual right of access (45 CFR 164.524(a)(1)), regardless of whether any given practice in any given scenario might not be considered “information blocking” on the basis of having satisfied any 45 CFR part 171 exception(s) to the definition codified in § 171.103.
                    </P>
                    <P>We welcome comment on this proposed new exception.</P>
                    <HD SOURCE="HD3">
                        5. Exceptions That Involve Practices Related to Actors' Participation in The Trusted Exchange Framework and Common Agreement
                        <SU>TM</SU>
                         (TEFCA
                        <SU>TM</SU>
                        )
                    </HD>
                    <P>
                        In the HTI-1 Proposed Rule (88 FR 23872), we proposed to add a 
                        <E T="03">TEFCA</E>
                        <SU>TM</SU>
                          
                        <E T="03">manner</E>
                         condition to the proposed revised and renamed Manner Exception. We stated that this approach “aligns with the Cures Act's goals for interoperability and the establishment of TEFCA by acknowledging the value of TEFCA in promoting access, exchange, and use of EHI in a secure and interoperable way” (88 FR 23872). In the HTI-1 Final Rule (89 FR 1437), in Part 171, we finalized a new subpart D “Exceptions That Involve Practices Related to Actors' Participation in The Trusted Exchange Framework and Common Agreement (TEFCA).” We noted that 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 subpart D by meeting all applicable requirements and conditions of the exception at all relevant times (89 FR 1388). We reserved § 171.401 for definitions in a future rulemaking, and also reserved § 171.402 for future use. In § 171.403 we finalized a new TEFCA Manner Exception based on the 
                        <E T="03">TEFCA manner</E>
                         condition we proposed in HTI-1 Proposed Rule.
                    </P>
                    <HD SOURCE="HD3">a. Definitions</HD>
                    <P>We stated that while we reserved § 171.401 for possible future use as a “definitions” section, we declined to finalize any definitions in the HTI-1 Final Rule and instead referred readers to the definitions in the most recent version of the Common Agreement (88 FR 76773) for the terms relevant to the new exception (89 FR 1388). 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 (86 FR 76778). We noted that this approach would allow us to maintain consistency and harmony between the Common Agreement and the new subpart D regulatory text.</P>
                    <P>
                        We now propose to include definitions in § 171.401 by cross-referencing the TEFCA definitions included in the proposed new 45 CFR part 172, “Trusted Exchange Framework and Common Agreement” (see section IV.B.5.a of this proposed rule). We specifically propose to adopt in § 171.401 the definitions from § 172.102 for the following terms: Common Agreement, Framework Agreement, Participant, QHIN
                        <SU>TM</SU>
                        , and Subparticipant. The definitions would apply to all of Subpart D. We welcome comment on this approach.
                    </P>
                    <HD SOURCE="HD3">
                        b. TEFCA
                        <SU>TM</SU>
                         Manner Exception
                    </HD>
                    <P>
                        As briefly discussed above, we finalized a new TEFCA Manner Exception in the HTI-1 Final Rule. We stated that the new TEFCA Manner Exception (§ 171.403) provides that an actor's practice of limiting the manner in which it fulfills a request to access, exchange, or use EHI to be providing such access, exchange, or use to only via TEFCA will not be considered information blocking when it follows certain conditions (89 FR 1388). Those conditions require that (1) the actor and requestor both be part of TEFCA; (2) that 
                        <PRTPAGE P="63643"/>
                        the requestor is capable of such access, exchange, or use of the requested EHI from the actor via TEFCA; and (3) 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). In addition to these three requirements, we also included a limitation in § 171.403(c), stating that the exception is available only if the request is not made via the standards adopted in 45 CFR 170.215, which include the FHIR API standards.
                    </P>
                    <P>
                        Our finalized TEFCA Manner Exception differed from the proposed 
                        <E T="03">TEFCA manner</E>
                         condition in two ways. First, when we proposed the 
                        <E T="03">TEFCA manner</E>
                         condition, we stated that the Fees Exception and the Licensing Exceptions would not apply, because “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 (See 88 FR 23872)” (89 FR 1389). We believe that by soliciting comments specifically on this point we provided notice to parties that we either would or would not apply the Fees and Licensing Exceptions. In response to our proposal, some commenters expressed concern that because the Common Agreement prohibits fees between QHINs
                        <SU>TM</SU>
                         but is otherwise silent on fees between Participants and Subparticipants, the proposal could allow actors to charge fees to access, exchange, or use EHI that did not comply with the Fees or Licensing Exceptions. Some commenters also expressed that this could have the effect of disincentivizing participation in TEFCA, and could cause actors to use other options of electronic exchange outside of TEFCA, where the actors believed the Fees and Licensing Exceptions would apply. As such, in the HTI-1 Final Rule, we finalized the TEFCA Manner 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) (89 FR 1389). While we continue to believe that it was clear that the alternative would be 
                        <E T="03">to</E>
                         apply the exceptions, we are requesting comment now on whether there are drawbacks to applying the Fees and Licensing Exceptions, and if we should continue to apply them to the TEFCA Manner Exception as currently required in § 171.403(d).
                    </P>
                    <P>
                        The other change made to the proposed 
                        <E T="03">TEFCA manner</E>
                         condition was the limitation that carves out requests made for access, exchange, or use of EHI via FHIR API standards (89 FR 1389). We finalized this limitation in response to comments noting that a request could be made for access, exchange, or use via FHIR-based API and an actor could respond in a different manner and satisfy the exception (89 FR 1390 through 91). Commenters further noted that this potential outcome could undermine our stated purpose in incentivizing TEFCA participation with the new exception (See 89 FR 1390). We now solicit comment on this limitation within the TEFCA Manner Exception for requests via FHIR API standards. For example, should the limitation be expanded to include exchange based on versions of the FHIR standards that are more advanced than those adopted in 45 CFR 170.215 or approved through the 45 CFR 170.405(b)(8) “Standards Version Advancement Process—voluntary updates of certified health IT to newer versions of standards and implementation specifications”? Currently, the limitation would only cover requests made via FHIR API standards codified in § 170.215, including standards that may be updated from time to time through § 170.405(b)(8), which may involve a delay before the version is formally approved under Standards Version Advancement Process (SVAP).
                    </P>
                    <P>We also seek comment on a different approach. Eventually all TEFCA QHINs will be required to support exchange via FHIR API standards. A Participant or Subparticipant who makes a request for access, exchange, or use of EHI via FHIR API will at first make such a request through a QHIN, but in time, a Participant or Subparticipant could directly request access, exchange, or use of EHI via FHIR API standards from another Participant or Subparticipant in a different QHIN. One option would be to sunset the limitation in § 171.403(c) once all QHINs can support brokered FHIR. Another option would be to sunset the limitation in § 171.403(c) if all QHINs, Participants and Subparticipants support facilitated FHIR exchange. As an alternative to these options, we could maintain the exception as is, regardless of FHIR API adoption among TEFCA entities. We request comment on all of the options, including whether or not the limitation should remain as it is currently.</P>
                    <HD SOURCE="HD1">
                        V. Trusted Exchange Framework and Common Agreement
                        <SU>TM</SU>
                    </HD>
                    <P>
                        Section 3001(c)(9)(B)(i) of the PHSA provides the National Coordinator with the authority to “develop or support a trusted exchange framework for trust policies and practices and for a common agreement for exchange between health information networks.” The components of this Trusted Exchange Framework and Common Agreement
                        <SU>TM</SU>
                         (TEFCA
                        <SU>TM</SU>
                        ) include the Trusted Exchange Framework (a common set of principles designed to facilitate trust between HINs) and the Common Agreement (the agreement Qualified Health Information Networks
                        <SU>TM</SU>
                         (QHINs
                        <SU>TM</SU>
                        ) sign), which includes, among other provisions, privacy, compliance, and security requirements). The Common Agreement also references the QHIN Technical Framework (QTF) (which describes technical requirements for exchange among QHINs) as well as, where necessary, standard operating procedures (SOPs). These documents further the statute's overall goal of ensuring full network-to-network exchange of health information by establishing a governance, policy, and technical floor for nationwide interoperability and securely facilitating the exchange of information across different networks nationwide.
                    </P>
                    <P>
                        By providing a common and consistent approach for the exchange of health information across many different networks, TEFCA simplifies and significantly reduces the number of separate networks of which individuals, health care providers, and other interested parties need to be a part of in order to access the health information they seek. TEFCA establishes a method for authenticating trusted health information network participants, potentially lowering the cost and expanding the nationwide availability of secure health information exchange capabilities. The establishment of technical services for health information networks that voluntarily join TEFCA creates interoperability at scale nationwide. These technical services, such as an electronic address directory and security services, will be critical to scale network exchange. In addition, the organizational and operational policies established through TEFCA enable the exchange of health information among health information networks and include minimum conditions required for such exchange to occur. Health information networks that voluntarily join TEFCA will facilitate exchange in a secure and interoperable manner. Updates in Common Agreement Version 2.0 reflect the latest technical specifications, among other changes, including updates to network-based exchange using FHIR® APIs, which are a cornerstone of the interoperability initiatives of not only ONC but also of other Federal agencies such as CMS, the 
                        <PRTPAGE P="63644"/>
                        CDC, HRSA, and the U.S. Department of Veterans Affairs Veterans Affairs.
                    </P>
                    <P>
                        Under TEFCA, QHINs play an important role in advancing secure, standardized health information exchange. QHINs have significant organizational and technical capabilities, facilitate exchange at the highest level of the TEFCA infrastructure, and are the entities with which Participants (and their Subparticipants) interact in order to engage in TEFCA Exchange. “TEFCA Exchange,” which we propose to define in § 172.102, means the transaction of electronic protected health information (ePHI) between Nodes 
                        <SU>255</SU>
                        <FTREF/>
                         using a TEFCA-specific purpose of use code, meaning a code that identifies the Exchange Purpose for which exchange is occurring. QHINs voluntarily agree to follow certain organizational and operational policies that allow Participants (entities who have entered into an agreement with the QHIN that includes the Participant/Subparticipant Terms of Participation) and Subparticipants (entities that have entered into an agreement with a Participant or other Subparticipant that includes the Participant/Subparticipant Terms of Participation) to simplify their operations and promote efficiency of scale.
                    </P>
                    <FTNT>
                        <P>
                            <SU>255</SU>
                             Node: a technical system that is controlled directly or indirectly by a QHIN, Participant, or Subparticipant and that is listed in the RCE Directory Service.
                        </P>
                    </FTNT>
                    <P>QHINs must meet policy and technical requirements under the Common Agreement. The QTF and SOPs provide additional information on how QHINs meet those requirements. If finalized, QHINs will have to comply with the provisions proposed in this proposed rule. QHINs also perform a vital role by ensuring that Participants and Subparticipants meet the requirements of TEFCA.</P>
                    <P>We propose to establish rules in 45 CFR part 172 to implement our obligations under section 3001(c)(9)(D) of the PHSA to publish a directory of health information networks that “have adopted the common agreement and are capable of trusted exchange pursuant to the common agreement” and to establish a process through notice-and-comment rulemaking for health information networks to attest to adopting the Trusted Exchange Framework and Common Agreement. These regulations would further our obligations to “support” TEFCA under sections 3001(c)(9)(A) and (B) of the PHSA. The provisions included in this proposed rule would establish the qualifications for health information networks to receive and maintain Designation as a QHIN capable of trusted exchange pursuant to TEFCA, as well as establish procedures governing QHIN Onboarding and Designation, suspension, termination, and administrative appeals to ONC as described in the sections below. We believe establishing these provisions in regulation would strengthen the trust of interested parties in TEFCA and support its success at scale.</P>
                    <HD SOURCE="HD2">A. Subpart A—General Provisions</HD>
                    <P>For the purposes of subpart A, we propose in § 172.100 the basis, purpose, and scope for the proposed TEFCA provisions in part 172 of Title 45 of the Code of Federal Regulations. We propose in § 172.100(a) that the basis for these provisions would be to implement section 3001(c)(9) of the PHSA (42 U.S.C 300jj-11(c)(9)). We propose in § 172.100(b) the dual purposes of proposed part 172: (1) to ensure full network-to-network exchange of health information; and (2) to establish a voluntary process for QHINs to attest to adoption of the Trusted Exchange Framework and Common Agreement. Section 172.100(b)(1) supports the statutory basis because the organizational and operational policies covered by part 172 would enable the exchange of health information among health information networks using the common set of rules found in these regulations. Section 172.100(b)(2) supports the statutory basis because it implements PHSA § 3001(c)(9)(D). We propose in § 172.100(c) the scope for part 172, which would include: (1) minimum qualifications needed to be Designated as a QHIN capable of trusted exchange under TEFCA; (2) procedures governing QHIN Onboarding and Designation, suspension, termination, and further administrative review; (3) attestation submission requirements for a QHIN to attest to its adoption of TEFCA; and (4) ONC attestation acceptance and removal processes for publication of the list of attesting QHINs in the QHIN Directory. In proposed § 172.101, we specify the applicability of part 172 by proposing that part 172 would apply only to Applicant QHINs, QHINs, and terminated QHINs. We note that our proposed QHIN definition in § 172.102 captures suspended QHINs (since a suspended QHIN is still a QHIN) and so we do not address them separately in proposed § 172.101. In § 172.102, we propose definitions for certain terms in part 172. We intend for the definitions provided in the Common Agreement to be consistent with these proposed definitions. Differences in phrasing would generally be attributable to differences in context, though in the case of any true conflict, we would intend for the regulatory definitions to control.</P>
                    <P>
                        Additionally, ONC has hired a contractor to help administer and implement TEFCA Exchange. This contractor, chosen through a competitive solicitation, is known as the Recognized Coordinating Entity® (RCE
                        <SU>TM</SU>
                        ). While the RCE is currently one entity, in the future, ONC may choose to assign some or all of its responsibilities to a different entity or multiple entities. Assigning to a different or multiple entities in the future could, for example, allow for more efficient use of resources or best leverage expertise. In § 172.103, “Responsibilities ONC may delegate to the RCE,” we propose that ONC may assign certain responsibilities to such an entity or entities for these purposes. Specifically, we propose in § 172.103(a)(1)-(4) that ONC may assign any of its responsibilities in Subpart C—QHIN Onboarding and Designation Process; Subpart D—Suspension, § 172.501 QHIN self-termination, and § 172.503 Termination by mutual agreement. In § 172.103(b), we propose that any authority exercised by the RCE under this section is subject to review by ONC under Subpart F (“Review of RCE Decisions”). For further discussion of the current RCE and the authority it exercises on behalf of ONC, please see the discussion in “
                        <E T="03">C. Subpart C—QHIN Onboarding and Designation Processes</E>
                        ” below.
                    </P>
                    <HD SOURCE="HD2">B. Subpart B—Qualifications for Designation</HD>
                    <P>
                        In subpart B, we propose qualifications for Designation. In § 172.200, we propose to tie QHIN status to meeting the requirements specified in § 172.201. We propose that an Applicant QHIN (as we propose to define it in § 172.102) would need to meet all requirements in § 172.201 to be 
                        <E T="03">Designated,</E>
                         and a QHIN would need to continue to meet all requirements in § 172.201 to 
                        <E T="03">maintain its Designation.</E>
                         That means that the requirements we propose in § 172.201 would be ongoing; a QHIN that does not meet those requirements at all times would be subject to suspension or termination, consistent with the regulations we propose in subparts D and E of part 172. Among other benefits, the continuing obligation to meet the requirements in § 172.201 would help to ensure the reliability of TEFCA Exchange and to ensure QHINs could not maintain their status based on technology and standards that have become obsolete. Because the obligations would be 
                        <PRTPAGE P="63645"/>
                        ongoing, throughout this section we refer to Applicant QHINs as well as Designated QHINs as “QHINs” unless there is a need to differentiate.
                    </P>
                    <P>As we explain below, the Designation qualifications proposed in § 172.201 would describe certain requirements for Designation. For an entity to become a QHIN, that entity must sign the Common Agreement, thus memorializing its agreement to the comprehensive Designation requirements—as well as other requirements—for trusted exchange under TEFCA. The comprehensive Designation requirements in the Common Agreement correspond to the proposed requirements included in this subpart.</P>
                    <P>In § 172.201, we propose Designation requirements in three categories: (a) ownership; (b) exchange requirements; and (c) Designated Network Services.</P>
                    <P>
                        In § 172.201(a), we propose the ownership requirements. In § 172.201(a)(1), we propose that a QHIN must be a U.S. Entity, as we propose to define 
                        <E T="03">U.S. Entity/Entities</E>
                         in § 172.102. Under that proposed definition, a U.S. Entity must be a corporation, limited liability company, partnership, or other legal entity organized under the laws of a State or commonwealth of the United States or the Federal law of the United States, be subject to the jurisdiction of the United States and the State or commonwealth under which it was formed, and have its principal place of business be in the United States under Federal law. Additionally, we propose that none of the entity's directors, officers, or executives, and none of the owners with a five percent (5%) or greater interest in the entity, may be listed on the 
                        <E T="03">Specially Designated Nationals and Blocked Persons List</E>
                         published by the United States Department of the Treasury's Office of Foreign Asset Control or on the Department of Health and Human Services, Office of Inspector General's List of Excluded Individuals/Entities. This requirement would help to promote organizational and operational policies that enable the exchange of health information among networks by ensuring that those who actually control the health information exchanged under these provisions are subject to U.S. laws, and it would help to avoid giving access to that information to actors whom the government has previously identified as national security or fraud risks.
                    </P>
                    <P>We request comment on whether the above approach, including the specific five percent (5%) threshold, will effectively limit access of bad actors trying to join TEFCA as a QHIN, or whether commenters believe the threshold should be a different percentage.</P>
                    <P>In § 172.201(a)(2), we propose that an Applicant QHIN must not be under Foreign Control, which is a term we propose to define in § 172.102. If, in the course of reviewing a QHIN application, ONC believes or has reason to believe the Applicant QHIN may be under Foreign Control, ONC will refer the case to the HHS Office of National Security (ONS) for review. If information available to ONS supports a determination of Foreign Control, ONS will notify ONC. An application will be denied if ONS notifies ONC that the Applicant is under Foreign Control. Given the scale of the responsibilities that a Designated QHIN would have with respect to supporting health information exchange and the importance that healthcare data has to the critical infrastructure of our nation's health care system, we believe that a QHIN should not be under Foreign Control. We believe the requirements proposed in § 172.201(a)(1) and (a)(2), in conjunction with the proposed definitions that those provisions reference, are necessary to ensure that all QHINs are subject to United States law and that compliance by QHINs is enforceable under United States law. Further, these proposals are designed to strengthen the security of the network. We believe that the above proposals promote organizational and operational policies that enable the exchange of health information among networks by minimizing the risk to TEFCA that may be posed by foreign state actors who wish to harm the United States, lessening the risks of subjecting QHINs to potentially conflicting foreign laws, and encouraging trust in the security of exchange under the system.</P>
                    <P>
                        We note that within the proposed definition of 
                        <E T="03">U.S. Entity/Entities</E>
                         in § 172.102, we propose that for an entity seeking to become a QHIN to meet the definition, none of the entity's directors, officers, or executives, and none of the owners with a five percent (5%) or greater interest in the entity, can be listed on the 
                        <E T="03">Specially Designated Nationals and Blocked Persons List</E>
                         published by the United States Department of the Treasury's Office of Foreign Asset Control or on the Department of Health and Human Services, Office of Inspector General's List of Excluded Individuals/Entities. We believe the five percent (5%) threshold strikes the right balance between protecting the security of the network from high-risk or known bad actors and achieving practical administrability of TEFCA. Individuals with less than five percent (5%) ownership in an entity would likely have limited means of influencing the actions of an entity connected to TEFCA. We believe that entities—particularly those with a large number of shareholders—would face undue hardship without this sort of exception for small shareholders. That said, this regulation only would provide the standard that ONC will apply when evaluating QHINs; it would not supersede any stricter requirements imposed by other applicable laws, including, for example national security laws. It remains the responsibility of QHINs (and any other entity) to comply with all applicable laws.
                    </P>
                    <P>In § 172.201(b), we propose exchange requirements for QHINs. We believe these exchange requirements are necessary to build a data sharing infrastructure that is private and secure and that meets all the requirements of PHSA section 3001(c)(9). We believe each of the exchange requirements below is important to the implementation and operationalization of TEFCA Exchange, as described in § 172.201, at scale. We propose that an entity seeking to become a QHIN must, beginning at the time of application, either directly or through the experience of its parent entity, meet certain exchange requirements, including: (1) be capable of exchanging information among more than two unaffiliated organizations; (2) be capable of exchanging all Required Information (as that term is defined in § 172.102); (3) be exchanging information for at least one of the Exchange Purposes (as that term is defined in § 172.102) authorized, in the Common Agreement or an SOP(s) n; (4) be capable of receiving and responding to transactions from other QHINs for all Exchange Purposes; and (5) be capable of initiating transactions for the Exchange Purposes that such entity will permit its Participants and Subparticipants to use through TEFCA Exchange. Collectively, we believe these requirements are tailored to help ensure that a QHIN is capable of TEFCA Exchange, supports a trusted exchange framework, and maintains consistent practices of exchanging information at scale to support nationwide interoperability.</P>
                    <P>
                        The first requirement, proposed in § 172.201(b)(1), that the entity seeking to become a QHIN be capable of exchanging information among more than two unaffiliated organizations, is a requirement that would ensure a minimum technical ability exists and that exchange would be enabled beyond just the QHIN itself.
                        <PRTPAGE P="63646"/>
                    </P>
                    <P>
                        The second requirement, proposed in § 172.201(b)(2), is also a minimum condition, except it is directed at the minimum quantity of 
                        <E T="03">data</E>
                         a QHIN must be capable of exchanging. This proposed requirement would ensure that every QHIN can exchange Required Information (as that term is defined in § 171.102), and provides certainty to Participants and Subparticipants who seek to join a QHIN that there is a minimum scope of data that they can reliably expect to be able to exchange via TEFCA Exchange Purposes.
                    </P>
                    <P>The proposed requirements in § 172.201(b)(3) through (5) are intended to establish basic parameters and expectations for QHINs in order to qualify for Designation. We propose, in § 172.201(b)(3), that a QHIN or Applicant QHIN must be exchanging information for at least one Exchange Purpose.</P>
                    <P>If a QHIN is not exchanging information for at least one of the Exchange Purposes authorized under TEFCA (for examples, see the “Exchange Purpose” definition in § 172.102) at the time of application, it is not meeting a minimum condition necessary for such exchange to occur and cannot be Designated. While exchange for an Exchange Purpose under TEFCA requires an Exchange Purpose Code, Applicant QHINs can demonstrate that they are meeting the requirement to exchange information for at least one of the Exchange Purposes by conducting exchange for an Exchange Purpose without use of an Exchange Purpose Code.</P>
                    <P>We propose in § 172.201(b)(4) to require a QHIN to be capable of receiving and responding to transactions from other QHINs for all Exchange Purposes, to ensure that health information can be exchanged among health information networks under TEFCA. For this same reason, we propose in § 172.201(b)(5) to require a QHIN to be capable of initiating transactions for the Exchange Purposes that such entity will permit its Participants and Subparticipants to use through TEFCA Exchange. Ensuring that QHINs will respond to Participant or Subparticipant requests for information, and that the Participants or Subparticipants are able to receive the information from QHINs, enables health information exchange among the QHINs, Participants and Subparticipants.</P>
                    <P>A QHIN's ability to transact for all Exchange Purposes is a threshold requirement for an entity that seeks Designation and is essential for ensuring that the TEFCA framework facilitates exchange for each Exchange Purpose authorized in the Common Agreement or an SOP(s) for implementation. Without this requirement, there would be no certainty that the TEFCA framework would advance exchange beyond the Treatment Exchange Purpose, which is the most prevalent purpose for health information exchange today and the purpose of use that most health care entities seeking Designation would be most familiar with. TEFCA's network connectivity, including this requirement that QHINs have the ability to exchange for all Exchange Purposes, and scale would help, for example, health care providers gain access to more comprehensive and complete information about their patients, which can support improved care, better outcomes, decreased provider burden, and reduced costs.</P>
                    <P>Entities performing TEFCA Exchange as described in § 172.201 will have the option to request information for all Exchange Purposes. At the time of publication of this Proposed Rule, TEFCA supports exchange for the following Exchange Purposes: treatment; payment; health care operations; public health; Individual Access Services (IAS), and government benefits determination. Over time, additional Exchange Purposes may be added. Information regarding whether responses are required for a given Exchange Purpose will be included in a TEFCA standard operating procedure.</P>
                    <P>In § 172.201(c), we propose that an Applicant QHIN must meet certain Designated Network Services requirements. Based on our experience in the health IT ecosystem, we believe adequate network performance is important for the success of TEFCA, as those participating in TEFCA Exchange would be most likely to trust the TEFCA infrastructure if it is performing at a high level. Unreliable network performance would dilute confidence in the network and discourage participation.</P>
                    <P>In § 172.201(c)(1), we propose that a QHIN must maintain the organizational infrastructure and legal authority to operate and govern its Designated Network. For instance, under this proposal, QHINs would be required to have a representative and participatory group or groups that approve the processes for fulfilling the TEFCA governance functions and that participate in governance for the Designated Network. In § 172.201(c)(2), we propose that a QHIN must maintain adequate written policies and procedures to support meaningful TEFCA Exchange as described in § 172.201 and fulfill all responsibilities of a QHIN in this part (which an entity agrees to by signing the Common Agreement). For instance, under this proposal, QHINs would be required to have a detailed written policy that describes the oversight and control of the technical framework that enables TEFCA Exchange.</P>
                    <P>In § 172.201(c)(3), we propose that a QHIN must maintain a Designated Network (as proposed to be defined in § 172.102) that can support a transaction volume that keeps pace with the demands of network users. Since TEFCA is a nationwide network and will be used daily to support various health data needs to inform care delivery, quality assessments, public health, and health care operations, QHINs must be capable of transacting high volumes of data reliably and at scale. In § 172.201(c)(4), we propose that a QHIN must maintain the capacity to support secure technical connectivity and data exchange with other QHINs. One of the most fundamental aspects of interoperable network exchange is technical connectivity, which makes network-to-network exchange possible and, therefore, is important to include in this regulation.</P>
                    <P>
                        In §§ 172.201(c)(5)-(7), we propose certain requirements related to governance for TEFCA to ensure all QHINs are aligned and able to manage risk effectively. In § 172.201(c)(5), we propose that a QHIN must maintain an enforceable dispute resolution policy governing Participants in the Designated Network that permits Participants to reasonably, timely, and fairly adjudicate disputes that arise between each other, the QHIN, or other QHINs. This proposed requirement would afford flexibility to QHINs to establish their own dispute resolution process while ensuring the process is timely and fair. Disputes may arise for a variety of reasons, so the QHIN, as the entity overseeing its Participants, is best placed to handle such disputes in a way that minimizes disruptions for the rest of the network. Ensuring that a QHIN has such a dispute resolution policy would, therefore, likely minimize such disruptions. Similarly, in § 172.201(c)(6), we propose that a QHIN maintain an enforceable change management policy consistent with its responsibilities as a QHIN. A change management policy establishes the standard procedures to approve different types of changes to TEFCA documents (
                        <E T="03">e.g.,</E>
                         standard operating procedures) and policies and will help to avoid changes that are disruptive or in conflict across entities. In § 172.201(c)(7), we propose that a QHIN must maintain a representative and participatory group or groups with the 
                        <PRTPAGE P="63647"/>
                        authority to approve processes for governing the Designated Network. The participatory network governance built into the TEFCA infrastructure is important to ensure that the requisite engagement exists between QHINs, Participants, and Subparticipants participating in TEFCA Exchange. We believe the above requirements are fundamental aspects of a network-of-networks focused on participatory governance and the ability to adapt to an ever-changing health information exchange landscape.
                    </P>
                    <P>Regarding the proposed requirement in § 172.201(c)(7) specifically, we emphasize that TEFCA uses a representative and participatory governance structure. Representative and participatory governance gives those participating in the network a role in informing the policies and decisions that ultimately would affect them. Such a governance structure helps to motivate health care entities and their networks to voluntarily join TEFCA. We believe that requiring a QHIN to have a representative and participatory group or groups that has the ability to review and provide input on the governance requirements of the QHIN's Designated Network is an optimal approach for this requirement.</P>
                    <P>In § 172.201(c)(8), we propose that an entity seeking to become a QHIN must maintain privacy and security policies that permit the QHIN to support TEFCA Exchange. These policies currently include, but are not limited to, the following:</P>
                    <P>• Maintaining certification under a nationally recognized security framework by a qualified, independent third party that ensures its assessments are consistent with the NIST Cybersecurity Framework (CSF) (using both NIST 800-171 (Rev. 2) and NIST 800-53 (Rev. 5) as a reference), that reviews the QHIN's HIPAA Security Rule risk analysis (consistent with § 164.308(a)(1)(ii)(A)), and verifies all requirements for technical audits and assessments are met.</P>
                    <P>• Having a qualified, independent third party complete an annual security assessment consistent with the NIST Cybersecurity Framework (CSF) (using both NIST 800-171 (Rev. 2) and NIST 800-53 (Rev. 5) as a reference). The third party would review the QHIN for compliance with HIPAA Security Rule risk analysis requirements consistent with § 164.308(a)(1)(ii)(A). Additionally, the annual security assessment must include comprehensive internet-facing penetration testing, must include an internal network vulnerability assessment, and must use methodologies and security controls consistent with Recognized Security Practices, as defined by Public Law No: 116-321 (42 U.S.C. 17931 and 300jj-52).</P>
                    <P>• Employing a Chief Information Security Officer with executive-level responsibility.</P>
                    <P>• Disclosing any breaches of electronic protected health information (including disclosure of any such breaches within the three (3) years preceding applying to become a QHIN) to the RCE and to all QHINs that are likely impacted;</P>
                    <P>• Complying with 45 CFR part 164, subparts A, C, and E, as applicable, as if the QHIN were a covered entity as described in that regulation; and</P>
                    <P>• Maintaining and complying with a written privacy policy.</P>
                    <P>These policies and requirements will provide privacy and security protections for the health information that will be exchanged through TEFCA. All entities that elect to participate in TEFCA, including entities not regulated under HIPAA, will be expected to meet a high bar for privacy and security given the nature of the data being exchanged. Further, the policies would advance TEFCA exchange by making it clear to those interested in participating that privacy and security measures are in place. It is unlikely that an entity would wish to participate in a network without privacy and security standards, thereby inhibiting TEFCA exchange.</P>
                    <P>
                        To further support the security of TEFCA, we propose in § 172.201(c)(9), that a QHIN must maintain data breach response and management policies that support secure TEFCA Exchange. For instance, given the number of electronic connections TEFCA will support, a data breach response and management policy would support a transparent process and timely awareness of a data breach or other security events (
                        <E T="03">e.g.,</E>
                         ransomware attacks) which could enable the QHIN to manage secure connectivity services without disrupting patient care. These proposed policies and requirements reflect the available privacy and security standards.
                    </P>
                    <P>In § 172.201(c)(10), we propose that a QHIN must maintain adequate financial and personnel resources to support all its responsibilities as a QHIN, including, at a minimum, sufficient financial reserves or insurance-based cybersecurity coverage, or a combination of both. This requirement will help to provide stability to TEFCA in the event of unexpected financial or economic occurrences—whether system-wide or specific to individual QHINs.</P>
                    <P>
                        For instance, this requirement could be met if the QHIN has available a minimum amount of cash, cash equivalents, borrowing arrangements (
                        <E T="03">e.g.,</E>
                         a line of credit) or a mix of the three that is equal to six (6) calendar months of operating reserves. Regarding insurance requirements, a QHIN's general liability coverage and the cyber risk/technology coverage should each have limits of at least $2,000,000 per incident and $5,000,000 in the aggregate, which limits can be met through primary coverage, excess coverage, available internal funds, or a combination thereof. We note that the requirements proposed here may be insufficient for larger QHINs, and recognize that certain QHINs will meet and exceed these minimums.
                    </P>
                    <P>QHINs will be the central connection points for TEFCA Exchange, responsible for routing queries, responses, and messages among many participating entities and individuals. We propose, in § 172.201(c)(10), that QHINs must have sufficient financial resources and personnel capacity to perform such functions successfully. We also believe that QHINs must be prepared to address incidents should they arise and must have the ability to fulfill potential liability obligations, either through insurance, sufficient financial reserves, or some combination of the two.</P>
                    <P>One goal of TEFCA is to support patients gathering their healthcare information. In § 172.202, “QHINS that offer individual access services,” we propose Individual Access Services (IAS) requirements for a QHIN to obtain and maintain Designation under TEFCA if that QHIN voluntarily offers IAS. In § 172.202(a), we propose that a QHIN would be required to obtain express consent from any individual before providing IAS, as defined in § 172.102. We believe this is an important requirement so that individuals who use IAS that a QHIN offers are informed of the privacy and security practices that are being employed to protect their data. In § 172.202(b), we propose that a QHIN would be required to make publicly available a privacy and security notice that meets minimum TEFCA privacy and security standards to support transparent exchange practices. We believe this requirement would provide transparency to all individuals who are considering using IAS regarding how their data is protected and secured by a QHIN providing IAS.</P>
                    <P>
                        In § 172.202(c), we propose a QHIN that is the IAS provider for an individual, would be required to delete the individual's Individually Identifiable Information (as defined in § 172.102) maintained by the QHIN upon request by the individual except as prohibited by Applicable Law or where such information is contained in 
                        <PRTPAGE P="63648"/>
                        audit logs. We believe this requirement would provide individuals with reassurance that they control access to their data. We believe the carve out for audit logs is appropriate because audit logs are generally used to provide chronological records of system activities and should not be deleted. In § 172.202(d), we propose that a QHIN would be required to permit any individual to export in a computable format all of the individual's Individually Identifiable Information maintained by the QHIN as an IAS provider. We believe this requirement would ensure that individuals may access, control, and use their own data held by an IAS provider.
                    </P>
                    <P>In § 172.202(e), we propose that all Individually Identifiable Information the QHIN maintains must satisfy certain criteria, including: (1) all Individually Identifiable Information must be encrypted; (2) without unreasonable delay and in no case later than sixty (60) calendar days following discovery of the unauthorized acquisition, access, Disclosure, or Use of Individually Identifiable Information, the QHIN must notify, in plain language, each individual whose Individually Identifiable Information has been or is reasonably believed to have been affected by unauthorized acquisition, access, Disclosure, or Use involving the QHIN; and (3) a QHIN must have an agreement with a qualified, independent third-party credential service provider and must verify, through the credential service provider, the identities of individuals seeking IAS prior to the individuals' first use of such services and upon expiration of their credentials. We note that to the extent the QHIN is already required by Applicable Law to notify an individual as described in proposed § 172.202(e)(2), we are not proposing that it be required to duplicate such a notification. Lastly, the proposed requirement in § 172.202(e)(3) would set a baseline for proving the identity of IAS users that are requesting data via TEFCA Exchange.</P>
                    <P>In some ways, IAS providers—should we finalize these proposals in § 172.202—would meet requirements above and beyond what the HIPAA Rules require of covered entities or business associates, including providing individuals with the right to delete their data and a requirement to encrypt all Individually Identifiable Information, as we propose in § 172.202(c) and § 172.202(e)(1). Encryption is an industry standard practice to protect data, and we believe the requirement we propose in § 172.202(e)(1) would create strong security of data while not creating undue burden to implement. We believe these proposed requirements are important because IAS providers will not always be HIPAA covered entities or business associates. Establishing these IAS requirements would ensure that QHINs that are IAS providers will meet certain minimum privacy and security requirements to protect patient data while also advancing the goal of improving patients' ability to access their data.</P>
                    <P>We welcome comments on the proposed qualifications and requirements in this subpart.</P>
                    <HD SOURCE="HD2">
                        C. Subpart C—QHIN
                        <E T="51">TM</E>
                         Onboarding and Designation Processes
                    </HD>
                    <P>TEFCA establishes a universal floor for interoperability across the country through a network of networks. In 2019, ONC issued a Notice of Funding Opportunity and subsequently awarded a cooperative agreement to The Sequoia Project to serve as the RCE to support the implementation of TEFCA. In August 2023, ONC awarded The Sequoia Project a five-year contract to continue serving as the RCE.</P>
                    <P>To establish nationwide health information exchange, TEFCA calls for the Designation of QHINs—HINs that agree to the common policy, functional, and technical requirements for TEFCA Exchange. The QHIN Designation Requirements as described in § 172.201 define the baseline legal and technical requirements for secure information sharing on a nationwide scale—all under commonly agreed-to rules. Exchange through TEFCA simplifies connectivity and creates efficiency by establishing a standardized approach to exchange policies and technical frameworks.</P>
                    <P>
                        Under the 2019 to 2023 cooperative agreement 
                        <SU>256</SU>
                        <FTREF/>
                         and the current RCE contract,
                        <SU>257</SU>
                        <FTREF/>
                         the RCE's role has been to support the implementation of TEFCA, including the solicitation and review of applications from HINs seeking QHIN status and administration of the Designation and monitoring processes. For entities seeking Designation, the application provides the RCE with the information needed to determine a prospective QHIN's ability to meet its obligations and responsibilities for TEFCA Exchange. All work or activities conducted by the Sequoia Project in their capacity as the RCE under the RCE contract, including work or activities related to Designation, is conducted on behalf of ONC.
                    </P>
                    <FTNT>
                        <P>
                            <SU>256</SU>
                             Notice of Funding Opportunity (NOFO)—Trusted Exchange Framework and Common Agreement—Recognized Coordination Entity (RCE) Cooperative Agreement, 
                            <E T="03">https://www.healthit.gov/sites/default/files/facas/TEFCA%20NOFO_FINAL_508.pdf</E>
                            .
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>257</SU>
                             
                            <E T="03">See USASPENDING.gov, https://www.usaspending.gov/award/CONT_AWD_75P00123C00019_7570_-NONE-_-NONE-.</E>
                        </P>
                    </FTNT>
                    <P>
                        In subpart C of part 172, we describe the proposed QHIN Onboarding and Designation processes. 
                        <E T="03">Onboarding,</E>
                         as we propose to define it in § 172.102, is the process a prospective QHIN must undergo to become a QHIN and become operational in the production environment.
                        <FTREF/>
                        <SU>258</SU>
                          
                        <E T="03">Designation,</E>
                         on the other hand, we propose to define in § 172.102, as the written determination that an Applicant QHIN has satisfied all regulatory requirements and is now a QHIN.
                        <SU>259</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>258</SU>
                             87 FR 2822.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>259</SU>
                             87 FR 2818.
                        </P>
                    </FTNT>
                    <P>In § 172.300, we explain that subpart C of part 172 would establish, for QHINs, the application, review, Onboarding, withdrawal, and redetermination processes that ONC will follow for Designation. Establishing these processes will ensure that ONC (or an RCE) takes a consistent approach to QHIN Onboarding and Designation.</P>
                    <P>The first step in becoming a QHIN under TEFCA is submission of an application. In § 172.301, we propose to establish the information Applicant QHINs must submit in order to be Designated as a QHIN. We propose that an Applicant QHIN must submit: (1) a completed QHIN application; and (2) a signed copy of the Common Agreement. Regarding the first proposed requirement, in § 172.301(a), the application may be updated over time and the most recent version will be available on ONC's and the RCE's website. The application will specify what supporting documentation an Applicant QHIN must submit. We propose the second requirement in § 172.301(b) because the Applicant QHIN would sign the Common Agreement upon application, but the RCE would only countersign and create a binding agreement with the Applicant QHIN once the Applicant QHIN completes Onboarding and is Designated.</P>
                    <P>
                        The next step to becoming a QHIN is application review. In § 172.302, we propose a process, with required timelines and allowable extensions, for ONC (or an RCE) to review applications. We propose in § 172.302(a) that, on receipt of an application, ONC (or an RCE) will review the application to determine if the Applicant QHIN has completed all parts of the application and provided the necessary supporting documentation. Further, we propose that, if the QHIN Application is not complete, ONC (or an RCE) will notify the applicant in writing of the missing 
                        <PRTPAGE P="63649"/>
                        information within thirty (30) calendar days of receipt of the application. Last, we propose that ONC (or an RCE) may extend this period by providing written notice to the Applicant QHIN. We note that “written notice” throughout part 172 would include notice provided by email to the points of contact the Applicant QHIN listed in their application.
                    </P>
                    <P>We believe the above timeframe and allowable extensions would allow ONC (or an RCE) enough time to perform a thorough review of each application and ensure that ONC (or an RCE) is provided with the responses and supporting documentation needed to assess the merits of an application. We believe the 30-day review timeframe—along with the ability of ONC (or an RCE) to extend this period by providing written notice to the Applicant QHIN—strikes the right balance between moving an application forward as quickly as possible while still providing ONC (or an RCE) with enough time to conduct a review of the application to ensure it is complete and contains all the required material.</P>
                    <P>
                        We propose in § 172.302(b) that once the QHIN application is complete, ONC (or an RCE) will review the application to determine whether the Applicant QHIN satisfies the requirements for Designation set forth in § 172.201, and, if the Applicant QHIN proposes to provide IAS, the requirements set forth in § 172.202. We propose this step to make clear that ONC (or an RCE) will review an application not only for completeness but also to determine if the qualifications are met. We also propose ONC (or an RCE) would complete its review within sixty (60) calendar days of providing the Applicant QHIN with written notice that its application is complete. We further propose that ONC (or an RCE) may extend this period by providing written notice to the Applicant QHIN. We believe that sixty (60) calendar days will 
                        <E T="03">generally</E>
                         be an adequate amount of time to conduct a thorough, comprehensive review of the substance of the application. However, we are cognizant that there may be complex applications that require additional time for review and have, therefore, proposed that ONC (or an RCE) may extend this period by providing written notice to the Applicant QHIN.
                    </P>
                    <P>We propose in § 172.302(c) that ONC (or an RCE) may contact the Applicant while the application is being reviewed to request additional information. ONC (or an RCE) will provide the timeframe for responding to its request and the manner to submit additional information, which may be extended on written notice to the Applicant QHIN. We believe this provision would be beneficial because the Applicant QHIN will need to provide detailed responses that may be complex and will vary among Applicant QHINs. We anticipate there will often need to be a discussion between ONC (or an RCE) and the Applicant QHIN to reach a resolution and shared understanding. This provision would provide for this vital communication between ONC (or an RCE) and the Applicant QHINs. We propose that an Applicant QHIN must respond to ONC (or an RCE) within the timeframe ONC (or an RCE) identifies because ONC (or an RCE) will be in the best position to understand the complexity of the question and estimate a reasonable amount of time for the Applicant QHIN to respond. That said, we understand that each application, as well as the questions associated with each application, will vary significantly on a case-by-case basis and, therefore, are proposing that ONC (or an RCE) may extend the timeframe by providing written notice to the Applicant QHIN. We believe this approach creates appropriate flexibility regarding timing of Applicant QHIN responses, while still leaving the discretion to decide the need for and length of such extensions.</P>
                    <P>We propose in § 172.302(d) that failure to respond to a request within the proposed timeframe, or in the manner specified, is a basis for a QHIN Application to be deemed withdrawn, as set forth in § 172.305(c)). In such situations, we propose that ONC (or an RCE) would provide the Applicant QHIN with written notice that application has been deemed withdrawn. We believe this requirement is important to support an efficient application process and to ensure that Applicant QHINs respond to requests in a timely manner. We reiterate that under proposed § 172.302(c), as discussed above, the ONC (or an RCE) can extend the timeframe for responding to a request for information. An Applicant QHIN should request an extension if it does not believe it can meet the proposed response timeframe.</P>
                    <P>We propose in § 172.302(e) that if, following submission of the application, any information submitted by the Applicant QHIN becomes untrue or materially changes, the Applicant QHIN must notify ONC (or an RCE), in the manner specified by ONC (or an RCE), of such changes in writing within five (5) business days of the submitted material becoming untrue or materially changing. This proposed requirement takes into consideration the possibility that, over the course of ONC's (or an RCE's) review of an application, an Applicant QHIN's circumstances or information provided with the Applicant QHIN's application may change. This provision would ensure that if such changes occur, the Applicant QHIN would promptly notify ONC (or an RCE) of such changes. We believe, based on ONC's experience with health IT implementation and coordination efforts, that five (5) business days is enough time for the Applicant QHIN to notify ONC (or an RCE) of the change(s).</P>
                    <P>In § 172.303, we propose requirements related to QHIN approval and Onboarding. We propose in § 172.303(a) that an Applicant QHIN would have the burden of demonstrating its compliance with all qualifications for Designation in § 172.201, and, if the Applicant QHIN proposes to provide IAS, the qualifications in § 172.202. We propose in § 172.303(b) that if ONC (or an RCE) determines an Applicant QHIN meets the requirements for Designation set forth in § 172.201, and, if the Applicant QHIN proposes to provide IAS, the qualifications set forth in § 172.202, then ONC (or an RCE) will notify the Applicant QHIN in writing that it has approved its application, and the Applicant QHIN can proceed with Onboarding. These proposed requirements are important for ensuring that the Applicant QHIN is notified of its status and support the transparency and efficiency of the Onboarding process.</P>
                    <P>We propose in § 172.303(c) that an approved Applicant QHIN would be required to submit a signed version of the Common Agreement within a timeframe set by ONC (or an RCE). This proposed provision is important in addition to § 172.301(b) (which would require an Applicant QHIN to submit a signed version of the Common Agreement when applying) to ensure that, if the Common Agreement changes between the time the QHIN applies and when it is approved, the QHIN will have signed the most recent version. We did not propose a specific timeframe for submission, and instead propose to allow ONC (or an RCE) to set the timeframe for each Applicant QHIN, since we believe each timeframe should be tailored to the needs of the Applicant QHIN and the complexity of each application.</P>
                    <P>
                        We propose in § 172.303(d) that an approved Applicant QHIN must complete the Onboarding process set forth by ONC (or an RCE), including any tests required by ONC (or an RCE) to ensure the Applicant QHIN's network can connect to those of other QHINs, within twelve (12) months of approval of the QHIN application, unless that 
                        <PRTPAGE P="63650"/>
                        time is extended in ONC's (or an RCE's) sole discretion by up to twelve (12) months. Based on ONC's experience with health IT implementation and discussions with the current RCE, we believe the proposed twelve (12) month timeframe is sufficient time for approved Applicant QHINs to complete the Onboarding process including any tests with QHINs and other Applicant QHINs. We believe that timeframe strikes an appropriate balance between the need to onboard QHINs promptly and the need to ensure that all QHINs can connect immediately and seamlessly once Designated. We note that during the Onboarding process, the Applicant QHIN would have regular check-ins with ONC (or an RCE) to monitor the progress on any outstanding requirements, to coordinate technical testing, and to address any issues that could put the Applicant QHIN in jeopardy of failing to meet the proposed Onboarding timeframe detailed above.
                    </P>
                    <P>In § 172.304, we propose the specific procedural requirements for the Designation of QHINs. In § 172.304(a), we propose the process that would follow an Applicant QHIN's satisfaction of the Onboarding process requirements. We propose that once the Onboarding process requirements are satisfied, the Common Agreement would be countersigned and the Applicant QHIN would receive a written determination indicating that it had been provisionally Designated as a QHIN, along with a copy of the countersigned Common Agreement.</P>
                    <P>In § 172.304(b), we propose that within thirty (30) calendar days of receiving its written determination of provisional Designation, each QHIN would be required to demonstrate in a manner specified by ONC (or an RCE) that it has completed a successful transaction with all other in-production QHINs according to standards and procedures for TEFCA Exchange. This proposed provision is important because it would ensure that a Designated QHIN is able to exchange information with other QHINs, which is a core function of QHINs. We believe that the thirty (30)-day timeframe will afford a Designated QHIN ample time to move from testing to production. We also believe that the standards and procedures for such exchanges should remain flexible such that ONC (or an RCE) may update the requirements from time to time as appropriate.</P>
                    <P>We propose in § 172.304(c) that if a QHIN is unable to complete the requirement in § 172.304(b), described above, within the thirty (30)-day period provided, the QHIN would be required to provide to ONC (or an RCE) with a written explanation as to why the QHIN is unable to complete the requirement within the allotted time and include a detailed plan and timeline for completion of the requirement. We propose that ONC (or an RCE) will then review and approve or reject the QHIN's plan, basing its decision on the reasonableness of the explanation based on the specific facts and circumstances, within five (5) business days of receipt. We propose that if the QHIN fails to provide ONC (or an RCE) its plan or ONC (or an RCE) rejects the QHIN's plan, ONC (or an RCE) will rescind its approval of the application, rescind the provisional QHIN Designation, and deny the application. We believe these proposals would provide QHINs with the appropriate flexibility to request an extension if the circumstances do not allow the QHIN to meet the timeline. We believe the proposed five (5)-business day timeframe would provide ONC (or an RCE) with enough time to review the request and reach a decision regarding the request based on the information provided. We propose that within thirty (30) calendar days of the end of the term of the plan, each QHIN must demonstrate in a manner specified by ONC (or an RCE) that it has completed a successful transaction with all other in-production QHINs according to standards and procedures for TEFCA Exchange. We believe that the thirty (30)-day timeframe will afford a Designated QHIN ample time to move from testing to production.</P>
                    <P>In § 172.304(d), we propose that a QHIN Designation will become final sixty (60) days after a Designated QHIN has submitted its documentation, in a manner specified by ONC (or an RCE), that it has completed a successful transaction with all other in-production QHINs. This proposal will allow ONC (or an RCE) to exercise its ability to review a Designation.</P>
                    <P>In § 172.305, we propose requirements related to withdrawal of an application. In § 172.305(a), we propose that an Applicant QHIN may withdraw its application by providing ONC (or an RCE) with written notice in a manner specified by ONC (or an RCE). In § 172.305(b), we propose that an Applicant QHIN may withdraw its application at any point prior to Designation. In § 172.305(c), we propose that on written notice to the Applicant QHIN, an application may be deemed as withdrawn as a result of the Applicant QHIN's failure to respond to requests for information from ONC (or an RCE). We believe the approach in proposed § 172.305 would create an efficient process for ONC (or an RCE) to deem applications withdrawn if an Applicant QHIN fails to respond to requests for information, and also supports a flexible process by allowing an Applicant QHIN, for whatever reason, to decide to withdraw its application without penalty. Given the requirements placed on Applicant QHINs seeking to be Designated, we think it is reasonable to believe that some Applicant QHINs will need to withdraw their applications to address any number of issues that could arise during the application process.</P>
                    <P>In § 172.306, we propose that if an Applicant QHIN's application is denied, the Applicant QHIN will be provided with written notice that includes the basis for the denial. We do not propose a specific template that would be used to explain the basis of a denial, as such explanation would likely vary based on the specific facts and circumstances.</P>
                    <P>In § 172.307, we propose requirements for re-application. In § 172.307(a), we propose that Applicant QHINs may resubmit their applications by complying with the provisions of § 172.301 in the event that an application was denied or withdrawn. We note that re-application pursuant to § 172.307(a) would also be conditioned on meeting the requirements of proposed paragraphs (b)-(d) of § 172.307, as applicable. We propose in § 172.307(b) that an Applicant QHIN may reapply at any time after it has voluntarily withdrawn its application as specified in § 172.305(a). We want to create flexibility for Applicant QHINs to reassess their applications and, if desired, resubmit the application. We also believe that providing an Applicant QHIN that withdraws its application with discretion to choose when to re-apply would result in better applications and create administrative efficiency. This is because Applicant QHINs would be motivated to self-identify issues and correct them in a subsequent application. Also, Applicant QHINs that withdraw applications early would allow ONC (or an RCE) to avoid expending resources to review and identify such issues.</P>
                    <P>
                        In § 172.307(c), we propose that if ONC (or an RCE) deems an application to be withdrawn as a result of the Applicant QHIN's failure to respond to requests for information from ONC (or an RCE), then the Applicant QHIN may reapply by submitting a new application no sooner than six (6) months after the date on which its previous application was submitted. We propose that the Applicant QHIN must respond to the prior request for information and must include an explanation as to why no response was previously provided within the required timeframe. We propose in § 172.307(d) that if ONC (or 
                        <PRTPAGE P="63651"/>
                        an RCE) denies an application, the Applicant QHIN may reapply by submitting a new application consistent with the requirements in § 172.301, no sooner than six (6) months after the date shown on the written notice of denial. The application must specifically address the deficiencies that constituted the basis for denying the Applicant QHIN's previous application. We believe that six (6) months is an appropriate minimum time period for re-application because we would expect the Applicant QHIN to take such time to reconsider and address the deficiencies in its application. Our goal with such proposed requirements is that the Applicant QHIN will be thoughtful about its new application and will work to address the problems with its initial application.
                    </P>
                    <P>We believe the proposed six (6)-month minimum time period before re-application, in § 172.307(c) and (d), would support efficiency in the review process, as ONC (or an RCE) could shift its attention to other Applicant QHINs or issues while the Applicant QHIN whose application was withdrawn as a result of the Applicant QHIN's failure to respond to requests for information or denied reconsiders its application and addresses the previously identified deficiency or deficiencies. These requirements would also support efficiency in the application process, as ONC (or an RCE) should only allocate resources to review a re-application if the Applicant QHIN has clearly addressed outstanding questions and previously identified deficiencies. On the other hand, we believe that if an Applicant QHIN withdraws its application, then the Applicant QHIN is best positioned to determine when it is ready to re-apply. Because the Applicant QHIN that withdraws its application has not had its application denied or deemed withdrawn for failure to respond to ONC (or an RCE) requests for information, the Applicant QHIN may be prepared to reapply much sooner than is the case for Applicant QHINs that have had their application denied or deemed withdrawn. We welcome comments on the proposed processes and requirements in this subpart. Specifically, we request comment on whether the six-month timeframe for re-application after an application has been deemed to be withdrawn as a result of the Applicant QHIN's failure to respond to requests for information or has been denied is appropriate, as well as other timeframes we propose.</P>
                    <HD SOURCE="HD2">D. Subpart D—Suspension</HD>
                    <P>Within this subpart, we propose provisions associated with suspension, notice requirements for suspension, and the effect of suspension. In § 172.401, we propose provisions related to ONC (or the RCE) suspension of a QHIN or directed suspension of a Participant or Subparticipant. In § 172.401(a), we propose that ONC (or an RCE) may suspend a QHIN's authority to engage in TEFCA Exchange if the ONC (or an RCE) determines that a QHIN is responsible for a Threat Condition. Within the TEFCA infrastructure, QHINs are expected to meet a high bar for security, including, but not limited to, third-party certification to industry-recognized cybersecurity standards; compliance with the HIPAA Security Rule or the standards required by the HIPAA Security Rule; annual security assessments; designation of a Chief Information Security Officer; and having cyber risk coverage.</P>
                    <P>This proposed provision would support the overall security of TEFCA and align with the security requirements for QHINs by enabling ONC (or an RCE) to suspend a QHIN's authority to engage in TEFCA Exchange if the QHIN is responsible for a Threat Condition. According to the definition proposed in § 172.102, a Threat Condition may occur in three circumstances: (i) a breach of a material provision of a Framework Agreement that has not been cured within fifteen (15) calendar days of receiving notice of the material breach (or such other period of time to which contracting parties have agreed), which notice shall include such specific information about the breach that is available at the time of the notice; or (ii) a TEFCA Security Incident, as that term is defined in § 172.102; or (iii) an event that ONC (or an RCE), a QHIN, its Participant, or their Subparticipant has reason to believe will disrupt normal TEFCA Exchange, either due to actual compromise of, or the need to mitigate demonstrated vulnerabilities in, systems or data of the QHIN, Participant, or Subparticipant, as applicable; or through replication in the systems, networks, applications, or data of another QHIN, Participant, or Subparticipant; or (iv) any event that could pose a risk to the interests of national security as directed by an agency of the United States government. We propose this policy because we believe that in each of these situations, in order to protect the security of TEFCA Exchange, ONC (or an RCE) must be able to take immediate action to suspend a QHIN's authority to engage in TEFCA exchange and limit the potential effects of the Threat Condition.</P>
                    <P>In § 172.401(b), we propose if ONC (or an RCE) determines that one of a QHIN's Participants or Subparticipants has done something or failed to do something that results in a Threat Condition, ONC (or an RCE) may direct the QHIN to suspend that Participant's or Subparticipant's authority to engage in TEFCA Exchange. This provision proposes to extend the ONC (or an RCE's) authority to suspend a QHIN's authority to engage in TEFCA Exchange to also include the authority to order a QHIN to suspend a Participant's or Subparticipant's authority to engage in TEFCA Exchange. We believe this provision would help protect the security of TEFCA Exchange because any Threat Condition—whether due to the action or inaction by a QHIN, Participant, or Subparticipant—could jeopardize the security of TEFCA and must be addressed once identified. We believe that in order to protect the security of TEFCA Exchange, ONC (or an RCE) must be able to take immediate action to order a QHIN to suspend a Participant's or Subparticipant's authority to engage in TEFCA Exchange and limit the potential effects of a Threat Condition resulting from something a Participant or Subparticipant has done or failed to do.</P>
                    <P>
                        In § 172.401(c), we propose that ONC (or an RCE) will make a reasonable effort to notify a QHIN in writing, in advance, of ONC's (or an RCE's) intent to suspend the QHIN or to direct the QHIN to suspend one of the QHIN's Participants or Subparticipants, and give the QHIN an opportunity to respond. Such notice would identify the Threat Condition giving rise to such suspension. We acknowledge that a suspension would significantly disrupt the activities of a QHIN, Participant, or Subparticipant and therefore § 172.401(c) proposes to require ONC (or an RCE) to make a reasonable effort to notify affected parties in advance of the ONC's (or an RCE's) intent to suspend. We propose to only require ONC (or an RCE) to make a reasonable effort to notify the entity because the circumstances surrounding a Threat Condition may limit ONC's (or an RCE's) ability to provide advance written notice to the QHIN or the QHIN's Participants or Subparticipants, despite ONC's (or an RCE's) best efforts. In § 172.401(d), we propose ONC (or an RCE) shall lift a suspension once the Threat Condition is resolved. We believe that it would no longer be necessary to continue a suspension once a Threat Condition is resolved.
                        <PRTPAGE P="63652"/>
                    </P>
                    <P>We believe the provisions outlined in § 172.401 would help maintain the integrity of TEFCA and offer a transparent approach to suspension that would communicate the reason for suspension, require timely notification of suspension, and afford QHINs an opportunity to resolve the issue(s), including in concert with their Participants or Subparticipants, that led to the suspension and resume TEFCA Exchange.</P>
                    <P>In § 172.402, we propose provisions related to selective suspension of TEFCA Exchange between QHINs. In § 172.402(a), we propose that a QHIN may, in good faith and to the extent permitted by Applicable Law, suspend TEFCA Exchange with another QHIN because of reasonable concerns related to the privacy and security of information that is exchanged. In § 172.402(b), we propose that if a QHIN decides to suspend TEFCA exchange with another QHIN, it is required to promptly notify, in writing, ONC (or an RCE) and the QHIN with which it is suspending exchange of its determination and the reason(s) for making the decision.</P>
                    <P>
                        These proposed provisions are intended to further strengthen the privacy and security protections within TEFCA by extending suspension rights to QHINs to suspend exchange with another QHIN due to reasonable concerns related to the privacy and security of information that is exchanged. We emphasize that we are proposing that the concerns must be “reasonable” 
                        <E T="03">and</E>
                         must be related to the “privacy and security of information that is exchanged” in order to ensure that suspension of TEFCA Exchange between QHINs is not based on other factors, such as competitive advantage. We solicit comments on examples of reasonable concerns related to the privacy and security of information that is exchanged. These proposed requirements would support trust between QHINs, which is a foundational element of TEFCA and would help TEFCA establish a universal floor for interoperability across the country. We believe prompt notification of the selective suspension to ONC (or an RCE) and the suspended QHIN would enable all parties involved to be aware of the situation in a timely fashion and take action to maintain the privacy and security of TEFCA Exchange activities.
                    </P>
                    <P>In § 172.402(c), we propose that if a QHIN suspends TEFCA Exchange with another QHIN under § 172.402(a), it must, within thirty (30) calendar days, initiate the TEFCA dispute resolution process in order to resolve the issues that led to the decision to suspend, or the QHIN may end its suspension and resume TEFCA Exchange with the other QHIN within thirty (30) calendar days of suspending TEFCA Exchange with the QHIN. We propose this provision to provide the parties with an opportunity to resolve concerns related to privacy and security and potentially continue exchange once the issues have been resolved. We believe the thirty (30)-day timeframe would provide sufficient time to resolve issues that led to the suspension, end the suspension, and resume TEFCA Exchange activities in a timely manner. Ultimately, TEFCA will be most impactful and successful if QHINs trust each other and are able to confidently exchange information with each other, so it is in the best interests of the QHINs involved, as well as TEFCA overall, to address and resolve a selective suspension quickly, and by the least disruptive means possible.</P>
                    <P>In § 172.402(d), we propose that, provided that a QHIN suspends TEFCA exchange with another QHIN in accordance with other provisions in § 172.402 and in accordance with Applicable Law, such selective suspension would not be deemed a violation of the Common Agreement. This provision would promote the integrity of TEFCA by ensuring that a QHIN with reasonable and legitimate concerns related to the privacy and security of information that is exchanged would not be deterred from suspending exchange activities with another QHIN for fear of being in violation of the Common Agreement.</P>
                    <P>We welcome comments on the proposed processes and requirements in this subpart.</P>
                    <HD SOURCE="HD2">E. Subpart E—Termination</HD>
                    <P>In this subpart, we propose provisions related to a QHIN's right to terminate its own Designation, ONC's (or an RCE's) obligation to terminate a QHIN's Designation and related notice requirements, and requirements related to the effect of termination. In § 172.501, we propose that a QHIN may terminate its own QHIN Designation at any time without cause by providing ninety (90) calendar days prior written notice. This provision supports the voluntary nature of TEFCA by allowing a QHIN that, for whatever reason, no longer wants to serve as a QHIN, to terminate its own QHIN Designation with ninety (90) business days prior written notice. We believe a QHIN should be able to terminate its Designation, regardless of the circumstances or reason and that ninety (90) business days would provide enough time for ONC, the RCE and the departing QHIN to analyze and address the impacts of the QHIN's departure.</P>
                    <P>In § 172.502, we propose that a QHIN's Designation will be terminated with immediate effect by ONC (or an RCE) giving written notice of termination to the QHIN if the QHIN: (a) fails to comply with any regulations of this part and fails to remedy such material breach within thirty (30) calendar days after receiving written notice of such failure; provided, however, that if a QHIN is diligently working to remedy its breach at the end of this thirty (30) day period, then ONC (or an RCE) must provide the QHIN with up to another thirty (30) calendar days to remedy its material breach; or (b) a QHIN breaches a material provision of the Common Agreement where such breach is not capable of remedy. We request comments on examples of material provisions of the Common Agreement where a breach is not capable of remedy.</P>
                    <P>We believe these proposals would promote transparency in TEFCA and strengthen the underlying trust among and between entities connected to TEFCA. These termination provisions would enable ONC (or an RCE) to take swift action to remove a non-complaint QHIN and ensure that entities that fail to meet their obligations as QHINs (by failing to comply with the regulations of this Part or by breaching a material provision of the Common Agreement) are no longer able to act as QHINs under the TEFCA framework. Without the ability for ONC (or an RCE) to terminate non-compliant QHINs, this trust—which is foundational to TEFCA and necessary for the ultimate success of TEFCA—could quickly erode and undermine TEFCA's progress.</P>
                    <P>In § 172.503, we propose that QHINs and ONC (or an RCE) would be able to terminate the QHIN's Designation at any time and for any reason by mutual, written agreement. Allowing two parties to terminate an agreement by mutual, written agreement ensures that two parties are not forced to follow an agreement that neither wants to follow. ONC believes it is reasonable and efficient to allow termination at any time where both ONC (or an RCE) and the QHIN are satisfied that a QHIN's termination is in the best interest of all.</P>
                    <P>We welcome comments on the proposed processes and requirements in this subpart.</P>
                    <HD SOURCE="HD2">F. Subpart F—Review of RCE® or ONC Decisions</HD>
                    <P>
                        ONC oversees the RCE's work and has the right to review the RCE's conduct and its execution of nondiscrimination and conflict of interest policies that demonstrate the RCE's commitment to treating QHINs in a transparent, fair, 
                        <PRTPAGE P="63653"/>
                        and nondiscriminatory way.
                        <SU>260</SU>
                        <FTREF/>
                         This subpart proposes to establish processes for review of RCE or ONC actions, including QHIN appeal rights and the process for filing an appeal. These appeal rights would ensure that a QHIN or Applicant QHIN that disagrees with certain RCE or ONC decisions will have recourse to appeal those decisions. Our proposed § 172.600 reflects this overall scope as an applicability section for this subpart.
                    </P>
                    <FTNT>
                        <P>
                            <SU>260</SU>
                             
                            <E T="03">See</E>
                             Common Agreement Section 3.1, 
                            <E T="03">https://www.federalregister.gov/documents/2024/05/01/2024-09476/notice-of-publication-of-common-agreement-for-nationwide-health-information-interoperability-common.</E>
                        </P>
                    </FTNT>
                    <P>In § 172.601, we propose provisions to establish ONC's authority to review RCE determinations, policies, and actions, as well as procedures for exercising such review. We propose in § 172.601(a) that ONC may, in its sole discretion, review all or any part of any RCE determination, policy, or action. In § 172.601(b) we propose ONC may, in its sole discretion and on notice to affected QHINs or Applicant QHINs, stay any RCE determination, policy, or other action. In § 172.601(c), we propose ONC may, in its sole discretion and on written notice, request that a QHIN, Applicant QHIN, or the RCE provide ONC additional information regarding any RCE determination, policy, or other action. In § 172.601(d), we propose that on completion of its review, ONC may affirm, modify, or reverse the RCE determination, policy, or other action under review. Additionally, we propose to provide notice to affected QHINs or Applicant QHINs that includes the basis for ONC's decision. In § 172.601(e), we propose ONC will provide written notice under this section to affected QHINs or Applicant QHINs in the same manner as the original RCE determination, policy, or other action under review. We believe these proposals provide transparency into the level of oversight ONC has in reviewing RCE determinations, policies, or actions and firmly establish ONC's authority to affirm, modify, or reverse such determinations, policies, and actions. We believe these provisions are important to assure QHINs and Applicant QHINs that we have the ability to effectively exercise oversight of the RCE, as well as provide all parties with an interest in the administration of TEFCA with confidence that we can and will take necessary action to ensure that QHINs and Applicant QHINs comply with the regulations we propose in part 172.</P>
                    <P>In § 172.602, we propose to establish bases for Applicant QHINs and QHINs to appeal decisions to ONC. We propose that an Applicant QHIN or QHIN may appeal certain decisions to ONC or a hearing officer, as appropriate. In § 172.602(a)(1), we propose that an Applicant QHIN would be able to appeal the denial of its application. In § 172.602(a)(2), we propose that a QHIN would be able to appeal a decision to (1) suspend a QHIN or instruct a QHIN to suspend its Participant or Subparticipant; or (2) terminate a QHIN's Common Agreement. We request comment on the proposed bases for appeal.</P>
                    <P>
                        In § 172.603, we propose the method and timing for filing an appeal. In § 172.603(a), we propose that to initiate an appeal, an authorized representative of the Applicant QHIN or QHIN must submit electronically, in writing to ONC, a notice of appeal that includes the date of the notice of appeal, the date of the decision being appealed, the Applicant QHIN or QHIN who is appealing, and the decision being appealed within fifteen (15) calendar days of the Applicant QHIN's or QHIN's receipt of the notice of (1) denial of an application, (2) suspension or instruction to suspend its Participant or Subparticipant, or (3) termination. With regard to an appeal of a termination, the fifteen (15) calendar day timeframe may be extended by ONC up to another fifteen (15) calendar days if the QHIN has been granted an extension for completing its remedy under § 172.502(a). The notice of appeal would serve to notify ONC that the Applicant QHIN or QHIN is planning to file an appeal and would require inclusion of only the minimum amount of information necessary to provide such notice (
                        <E T="03">i.e.,</E>
                         the date of the notice of appeal, the date of the decision being appealed, the Applicant QHIN or QHIN who is appealing, and what is being appealed). As such, we believe fifteen (15) business days would be an adequate amount time for deciding whether to initiate an appeal and submitting such information.
                    </P>
                    <P>In § 172.603(b), we propose that an authorized representative of an Applicant QHIN or QHIN must submit electronically, to ONC, within thirty (30) calendar days of filing the intent to appeal: (1) A statement of the basis for appeal, including a description of the facts supporting the appeal with citations to documentation submitted by the QHIN or Applicant QHIN; and (2) Any documentation the QHIN would like considered during the appeal.</P>
                    <P>We expect that it would take an Applicant QHIN or QHIN some time to collect all of the relevant information and documentation to support its appeal, and accordingly have proposed a timeframe for requesting an appeal of thirty (30) calendar days from the filing of the intent to appeal with ONC. We welcome comments on whether this timeframe, as well as the timeframe for submitting an intent to appeal, are adequate and appropriate.</P>
                    <P>In § 172.603(c), we propose that an Applicant QHIN or QHIN filing the appeal may not submit on appeal any evidence it did not submit prior to the appeal, except by permission of the hearing officer. We believe this provision balances a QHIN or Applicant QHIN's right to introduce evidence with the need for orderly proceedings. We are aware that under our proposed regulations, QHINs facing suspension or termination do not have an express right to introduce evidence. We solicit comments on whether and when a QHIN facing suspension or termination should have a right to introduce that evidence—for example as part of demonstrating that a material breach has been remedied or is capable of remedy under § 172.502, at the hearing officer stage, or some combination of the two based on circumstances of the suspension or termination.</P>
                    <P>In § 172.604, we propose that an appeal would not stay a suspension or termination, unless otherwise ordered by ONC or the hearing officer assigned under § 172.605(b). This means that in the event of an appeal of a suspension or termination, the appeal would not stop the suspension or termination from being effective. We believe this proposed approach is important because a QHIN would only be suspended or terminated for infractions that could, for example, jeopardize the privacy and security of TEFCA Exchange.</P>
                    <P>Before a QHIN is terminated under § 172.502(a), the QHIN would have already been given an opportunity to remedy the breach unless the breach is not capable of remedy. The move by ONC or and RCE to terminate a QHIN would mean either the QHIN tried and failed to remedy the issue, or a remedy is not possible. In either case, we believe it would be appropriate not to stay the termination. In the case of a suspension, the QHIN would have been found to be responsible for a Threat Condition, and we believe the risk to the privacy and security of the TEFCA ecosystem would far outweigh any perceived benefit of staying the suspension.</P>
                    <P>
                        In § 172.605, we propose provisions related to the assignment of a hearing officer. In § 172.605(a), we propose that, in the event of an appeal, the National Coordinator may exercise authority under § 172.601 to review the RCE determination being appealed. We 
                        <PRTPAGE P="63654"/>
                        further propose an appealing QHIN or Applicant QHIN that is not satisfied with ONC's subsequent determination may appeal that determination to a hearing officer by filing a new notice of appeal and other appeal documents that comply with § 172.603. In § 172.605(b), we propose if ONC declines review under subsection (a), or if ONC made the determination under review, ONC would arrange for assignment of the case to a hearing officer to adjudicate the appeal.
                    </P>
                    <P>We specify in proposed § 172.605(c) that the hearing officer must be an officer appointed by the Secretary of Health and Human Services (for more information about officers and appointments, see section III.D.5.c, above). In § 172.605(d), we propose, the hearing officer may not be responsible to, or subject to the supervision or direction of, personnel engaged in the performance of investigative or prosecutorial functions for ONC, nor may any officer, employee, or agent of ONC engaged in investigative or prosecutorial functions in connection with any adjudication, in that adjudication or one that is factually related, participate or advise in the decision of the hearing officer, except as a counsel to ONC or as a witness.</P>
                    <P>
                        In § 172.606, we propose requirements related to adjudication. In § 172.606(a), we propose that the hearing officer would decide issues of law and fact 
                        <E T="03">de novo</E>
                         and would apply a preponderance of the evidence standard when deciding appeals. 
                        <E T="03">De novo</E>
                         review means that the hearing officer would decide the issue on appeal without deference to a previous decision (
                        <E T="03">i.e.,</E>
                         ONC's or the RCE's decision to (1) deny an application, (2) suspend a QHIN or to instruct a QHIN to suspend its Participant or Subparticipant, or (3) terminate a QHIN's Common Agreement). We believe 
                        <E T="03">de novo</E>
                         review is appropriate for appeals by Applicant QHINs or QHINs because ONC ultimately has responsibility for TEFCA operations and implementation, even though the RCE is a contractor acting on ONC's behalf. Given the gravity and potentially significant implications (financial, effect on existing contracts, etc.) of a denied application, suspension, or termination, we believe the hearing officer assigned by the National Coordinator should make an independent decision, taking all of the facts and evidence the parties present into consideration.
                    </P>
                    <P>
                        The “preponderance of the evidence” standard means the burden of proof is met when the party with the burden (the appealing Applicant QHIN or QHIN) convinces the fact finder (hearing officer) that there is a greater than 50% chance that the claim is true. This standard is used in most civil cases and would only require the appealing party to show that a particular fact or event was more likely than not to have occurred. We believe this threshold creates the right balance for requiring an appealing Applicant QHIN or QHIN to make a strong case to succeed on appeal, while not imposing a standard that would be extremely difficult for the appeal Applicant QHIN or QHIN to meet. We request comment on whether the “preponderance of the evidence” is the appropriate standard, or if another standard (
                        <E T="03">e.g.,</E>
                         clear and convincing evidence, beyond a reasonable doubt, etc.) would be more suitable.
                    </P>
                    <P>In § 172.606(b), we propose that a hearing officer would make a determination based on the written record or any information from a hearing conducted in-person, via telephone, or otherwise (for example, via video teleconference). We propose that the written record would include ONC's or the RCE's determination and supporting information, as well as all appeal materials submitted by the Applicant QHIN or QHIN pursuant to § 172.603. We propose these requirements for the written record because it is important that the written record reflect both the position of ONC or the RCE and the Applicant QHIN or QHIN. We propose that the hearing officer would have sole discretion to conduct a hearing in certain situations. We propose that the hearing officer could conduct a hearing to require either party to clarify the written record under paragraph (b)(1) of this section. Last, we propose that the hearing officer could conduct a hearing if they otherwise determine a hearing is necessary. We believe the last provision is necessary because it gives the hearing officer discretion to conduct a hearing based on the specific circumstances surrounding the appeal, even if the need for the hearing does not fit under the first or second criteria detailed above.</P>
                    <P>In § 172.606(c), we propose that a hearing officer would neither receive witness testimony nor accept any new information beyond what was provided in accordance with paragraph (b) of this section, except for good cause shown by the party seeking to submit new information. We believe this provision will help ensure that the appeals process is consistent and fair for all involved.</P>
                    <P>In § 172.607, we propose requirements related to a decision by the hearing officer. In § 172.607(a), we propose that the hearing officer would issue a written determination. We request comment on whether we should include a specific timeframe for issuing the written determination, or whether abstaining from including a specific timeframe is a better approach given the varying complexity and circumstances of each appeal.</P>
                    <P>To ensure accountability, and to ensure that the hearing officer's decisions would be subject to the discretionary review of a principal officer of the United States, we propose in § 172.607(b) that a hearing officer's decision on an appeal is the final decision of HHS unless within 10 business days, the Secretary, at the Secretary's sole discretion, chooses to review the determination. We also propose that ONC would notify the appealing party if the Secretary chooses to review the determination and once the Secretary makes his or her determination. This provision would also align § 172.607 procedures with the ONC Health IT Certification Program appeals procedures in § 170.580(g) as we propose to revise them in this Proposed Rule (see Section III.D.2.b of this preamble). We have not proposed a specific timeframe for the Secretary to complete their review (if the Secretary chooses to review) because we believe that if the Secretary makes the decision to review a hearing officer's determination, the Secretary would be informed enough on the issues of the case to determine an appropriate review timeframe.</P>
                    <P>We welcome comments on the proposed appeal processes outlined in this subpart.</P>
                    <HD SOURCE="HD2">
                        G. Subpart G—QHIN 
                        <E T="51">TM</E>
                         Attestation for the Adoption of the Trusted Exchange Framework and Common Agreement 
                        <E T="51">TM</E>
                    </HD>
                    <P>Section 4003(b) of the Cures Act added section 3001(c)(9), “Support for Interoperable Networks Exchange,” to the PHSA. Section 3001(c)(9)(D)(ii) requires HHS to establish, through notice and comment rulemaking, a process for HINs that voluntarily elect to adopt TEFCA to attest to such adoption of the framework and agreement. Section 3001(c)(9)(D)(i) also requires the National Coordinator to publish on ONC's website a list of the HINs that have adopted the Common Agreement and are capable of trusted exchange pursuant to the Common Agreement.</P>
                    <P>
                        QHINs are the only entities permitted to “adopt” the Common Agreement, which is accomplished by becoming a signatory to the Common Agreement. As such, we propose that only QHINs would be able to attest to the adoption of the Common Agreement and the Trusted Exchange Framework. While the Trusted Exchange Framework was 
                        <PRTPAGE P="63655"/>
                        foundational for creating the provisions of the Common Agreement, it is, as noted above, a separate set of principles. Therefore, we propose that for purposes of attesting to the adoption of the Trusted Exchange Framework, QHINs would be required to expressly attest to their agreement and adherence to the Trusted Exchange Framework.
                        <SU>261</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>261</SU>
                             The Trusted Exchange Framework (TEF): Principles for Trusted Exchange (January 2022), 
                            <E T="03">https://www.healthit.gov/sites/default/files/page/2022-01/Trusted_Exchange_Framework_0122.pdf.</E>
                        </P>
                    </FTNT>
                    <P>Once attestation is complete and deemed valid, QHINs would be publicly listed on ONC's website. This regulatory provision would implement the HIN attestation provision from the Cures Act and would provide benefits to the public, Federal partners, and interested parties. For example, a Federal website listing of attesting QHINs would make it easy for the public to identify whether an entity is or is not a QHIN and provide a resource for Federal partners to help determine whether participants in some of their programs also belong to a network that is recognized as a QHIN. Section 3001(c)(9)(E) provides the option for Federal agencies to require, under certain circumstances, adoption of TEFCA for health information exchange networks that they contract with or enter into agreements with.</P>
                    <P>To implement sections 3001(c)(9)(D)(i) and (ii) of the PHSA, we propose to establish subpart G in part 172 titled, “QHIN Attestation for the Adoption of the Trusted Exchange Framework and Common Agreement.”</P>
                    <P>We propose in § 172.700 that subpart G would establish the attestation submission requirements applicable to QHINs. In § 172.701, we propose attestation submission requirements for QHINs and review and acceptance processes that ONC will follow for TEFCA attestations. In § 172.701(b), we propose that in order to be listed in the QHIN Directory described in proposed § 172.702, a QHIN would be required to submit to ONC an attestation affirming agreement with and adherence to the Trusted Exchange Framework and its adoption of the Common Agreement. We further propose in § 172.701(b) that a QHIN would be required to submit to ONC identifying information consisting of its name, address, city, State, zip code, and a hyperlink to its website. We also propose that the QHIN would be required to submit to ONC identifying information about its authorized representative including the representative's name, title, phone number, and email address. We propose that a QHIN would also be required to provide documentation confirming its Designation as a QHIN. We also propose that a QHIN would be required to provide ONC with written notice of any changes to its identifying information provided in accordance with § 172.701 within 30 calendar days of the change(s) to its identifying information. We believe the above provisions provide clear instructions for submitting a QHIN attestation that will support a consistent and transparent QHIN attestation process and provides ONC with the information needed to identify the entity and contact the authorized representative.</P>
                    <P>We propose in § 172.701(c) that a QHIN must electronically submit its attestation and documentation specified in § 172.701(b) either via an email address identified by ONC or via a submission on the ONC website, if available. We propose in § 172.701(d) that once a QHIN has submitted its attestation and documentation, ONC would either accept or reject the submission within 30 calendar days. We propose that ONC would accept the submission if it determines that the QHIN has satisfied the requirements of §§ 172.701(b) and (c). In such instances, we propose that ONC would provide written notice to the applicable QHIN's authorized representative that the submission has been accepted. In § 172.701(d), we also propose that ONC would reject a submission if it determines that the requirements of § 172.701(b), § 172.701(c), or both, have not been satisfied. In such instances, we propose that ONC would provide written notice to the QHIN's authorized representative of the determination along with the basis for the determination. We propose that an ONC determination would be a final agency action and not subject to administrative review, except the Secretary may choose to review the determination as provided in § 172.607(b). However, we propose that a QHIN may, at any time, resubmit an attestation and documentation in accordance with §§ 172.701(b) and (c). We believe these submission procedures will support a consistent and transparent QHIN attestation process. We welcome comments on these procedures.</P>
                    <P>In § 172.702, we propose the requirements for a QHIN directory. We propose in § 172.702(a) that this subpart would establish processes for publishing a directory of QHINs on the ONC website. We propose in § 172.702(b)(1) that, within fifteen (15) calendar days of notifying a QHIN that its submission has been accepted, ONC would publish, at a minimum, the QHIN's name in the QHIN directory.</P>
                    <P>We propose § 172.702(b)(2) to identify within the QHIN directory those QHINs that have been suspended under the Common Agreement. A QHIN directory that includes QHINs that have adopted the Common Agreement and are capable of TEFCA Exchange and those QHINs suspended under the Common Agreement offers a transparent list of QHINs participating in TEFCA. As noted above, the QHIN directory may serve as a useful tool for the public, Federal partners, and other interested parties seeking information about QHINs. Therefore, we welcome comments regarding the information we propose to include in the QHIN directory.</P>
                    <P>We propose in § 172.702(c) to establish requirements for removal of a QHIN from the QHIN directory. We propose in § 172.702(c)(1) that ONC will remove a QHIN that is no longer eligible for QHIN status from the QHIN directory. We propose that a QHIN whose Common Agreement has been terminated would no longer be considered a QHIN and so would be removed from the QHIN directory. The removal of a QHIN whose Common Agreement has been terminated from the QHIN Directory would be a ministerial action by ONC.</P>
                    <P>
                        We propose in § 172.702(c)(2) that upon termination of a QHIN's Common Agreement, ONC (or an RCE) will send a written statement of intent to remove the QHIN from the QHIN Directory to the authorized representative of the QHIN. Under § 172.702(c)(3), we propose that the written statement would include, as appropriate, (i) the name of the terminated QHIN and the name and contact information of the authorized representative of the QHIN; (ii) a short statement setting forth findings of fact with respect to any violation of the Common Agreement or other basis for the QHIN's termination; (iii) other materials as the RCE may deem relevant. In § 172.702(d), we propose that a QHIN that is removed from the QHIN Directory would remain removed until a new attestation is accepted by ONC in accordance with the processes specified in subpart G of this part. In § 172.702(e), we propose that an ONC determination under § 172.702 is final agency action and not subject to further administrative review, except the Secretary may choose to review the determination as provided in § 172.607(b). We believe this proposal is appropriate because a QHIN would have had ample opportunity to appeal its termination under the provisions proposed in Subpart F of this Proposed Rule.
                        <PRTPAGE P="63656"/>
                    </P>
                    <P>We seek comments on alternative ways to structure the requirements to remove a QHIN from the QHIN directory.</P>
                    <HD SOURCE="HD1">VI. 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 propose to incorporate by reference in the Code of Federal Regulations (79 FR 66267; 1 CFR 51.5(a)). Specifically, § 51.5(a) requires agencies to discuss, in the preamble of a proposed rule, the ways that the materials it proposes to 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 proposed rule, the material it proposes to 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.A.1 of this preamble, we have followed the NTTAA and OMB Circular A-119 in proposing standards and implementation specifications for adoption, including describing any exceptions in the proposed 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 propose to adopt, and subsequently 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(a), we provide summaries of the standards we propose to adopt and subsequently incorporate by reference in the Code of Federal Regulations. We also provide relevant information about these standards and implementation specifications throughout the preamble.</P>
                    <P>
                        We have organized the following standards and implementation specifications that we propose to adopt through this rulemaking according to the sections of the Code of Federal Regulations (CFR) in which they would be codified and cross-referenced for associated certification criteria and requirements that we propose to adopt. We note, in certain instances, that we request comment in this proposed rule on multiple standards or implementation specifications that we are considering for adoption 
                        <E T="03">and incorporation by reference</E>
                         for particular use cases. We include all of these standards and implementation specifications in this section of the preamble.
                    </P>
                    <HD SOURCE="HD2">Content Exchange Standards and Implementation Specifications for Exchanging Electronic Health Information—45 CFR 170.205</HD>
                    <HD SOURCE="HD3">• HL7 CDA R2 IG: Consolidated CDA (C-CDA) Templates for Clinical Notes, Edition 3—US Realm (C-CDA Edition 3), May 18, 2024</HD>
                    <P>
                        <E T="03">URL: https://hl7.org/cda/us/ccda/.</E>
                    </P>
                    <P>This is a direct access link.</P>
                    <P>
                        <E T="03">Summary:</E>
                         C-CDA 3.0 merges the C-CDA R2.1 and the C-CDA Companion Guides, adds C-CDA enhancement requests, and incorporates new design and guidance for USCDI V4. Annual updates will occur to provide design for USCDI releases and to address comments or requests from the US Realm C-CDA community.
                    </P>
                    <HD SOURCE="HD3">• HL7 Version 2.5.1 Implementation Guide: Syndromic Surveillance, Release 1—US Realm Standard for Trial Use, July 2019</HD>
                    <P>
                        <E T="03">URL: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=503.</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>
                         The scope of this document is to provide guidelines for transmitting HL7 v.2.5.1-compliant messages that also conform with specific profiles that facilitate communications from emergency departments, urgent care centers, and ambulatory care and inpatient settings to the PHAs that conduct syndromic surveillance. The intent of this guide is to facilitate data exchange between different systems for syndromic surveillance purposes.
                    </P>
                    <HD SOURCE="HD3">• HL7 Version 2.5.1 Implementation Guide for Immunization Messaging, Release 1.5 2018 Update</HD>
                    <P>
                        <E T="03">URL: https://www.cdc.gov/vaccines/programs/iis/technical-guidance/hl7.html.</E>
                    </P>
                    <P>This is a direct access link.</P>
                    <P>
                        <E T="03">Summary:</E>
                         This document combines the original HL7 2.5.1 Release 1.5 Implementation Guide and Release 1.5 Addendum, as well as additional guidance published by AIRA. The purpose of this document is to provide a single document containing essential HL7 information, so that implementers and developers have a convenient single set of information to work from. Further, the new Appendix C provides references to additional guidance documents published by AIRAafter the release of the addendum.
                    </P>
                    <HD SOURCE="HD3">• HL7 Version 2.5.1 Implementation Guide: Laboratory Orders (LOI) from EHR, Release 1, STU Release 4—US Realm, December 3, 2013</HD>
                    <P>
                        <E T="03">URL: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=152.</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>
                         This implementation guide focuses on key points of broad interoperability, including use of strong identifiers for key information objects and use of vocabulary standards. This version supports additional data elements needed for newborn dried bloodspot screening (NDBS), Public Health reporting (PH) including pandemic response requirements, the 
                        <PRTPAGE P="63657"/>
                        ability to request withholding results reporting to patients/caregivers until the provider had the opportunity to share those results, and references to preliminary guidance to include SOGI/Gender Harmony data.
                    </P>
                    <HD SOURCE="HD3">• HL7 Version 2.5.1 Implementation Guide: Laboratory Results Interface (LRI), Release 1 STU Release 4—US Realm (Public Health Profile), July 16, 2012</HD>
                    <P>
                        <E T="03">URL: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=279.</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>
                         This guide provides guidance on how to communicate laboratory results in general from a (reference) Laboratory's LIS to a system interested in lab results, 
                        <E T="03">e.g.,</E>
                         EHR, Public Health, or other Laboratory. It covers general lab results, as well as specifications focused on micro-biology, newborn dried bloodspot screening, and clinical genomics. The guide includes particular guidance that can be pre-adopted to support pandemic response reporting to public health and references preliminary guidance to include SOGI/Gender Harmony data.
                    </P>
                    <HD SOURCE="HD3">• HL7 FHIR Central Cancer Registry Reporting Content IG, 1.0.0—STU 1, December 21, 2023</HD>
                    <P>
                        <E T="03">URL: https://build.fhir.org/ig/HL7/fhir-central-cancer-registry-reporting-ig/index.html.</E>
                    </P>
                    <P>This is a direct access link.</P>
                    <P>
                        <E T="03">Summary:</E>
                         This standard facilitates automated, standardized exchange of cancer surveillance data from ambulatory healthcare provider EHR systems to central cancer registries. The goal of this IG is to leverage existing technology frameworks and standards (
                        <E T="03">e.g.,</E>
                         minimal Common Oncology Data Elements (mCODE)), facilitate automated electronic collection and exchange, reduce reporting burden on data providers, augment secure transfers, and enhance data completeness, timeliness, and accuracy of cancer surveillance data using modern IT standards.
                    </P>
                    <HD SOURCE="HD3">• HL7 FHIR Cancer Pathology Data Sharing, 1.0.0—STU1, August 18, 2023</HD>
                    <P>
                        <E T="03">URL: https://build.fhir.org/ig/HL7/cancer-reporting/.</E>
                    </P>
                    <P>This is a direct access link.</P>
                    <P>
                        <E T="03">Summary:</E>
                         The Cancer Pathology Data Sharing implementation guide (IG) reporting process documents best practices for transmitting pathology data as FHIR resource bundles and distributing them to the Central Cancer Registry (CCR) via two pathways: (1) Laboratory Information Systems (LIS) to CCR via an EHR intermediary; and (2) LIS to CCR directly. This publication promotes structured data collection and exchange of cancer pathology data, provides the data model, defined data items and their corresponding code and value sets. This guide specifies the collection and exchange of data specific to a cancer pathology synoptic report for public health reporting. This guide contains a library of FHIR profiles to create a cancer pathology message bundle and is compliant with FHIR Release 4.
                    </P>
                    <HD SOURCE="HD3">• HL7 CDA® R2 Implementation Guide: Healthcare Associated Infection (HAI) Reports, Release 3—US Realm, December 2, 2020</HD>
                    <P>
                        <E T="03">URL: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=426.</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>
                         The implementation guide supports electronic submission of HAI data to the National Healthcare Safety Network (NHSN). The implementation guide enables more than 3000 hospitals in 22 States to meet requirements that Healthcare Associated Infection data be submitted through the NHSN to CDC and revises existing reports and adds new ones to collect data that is relevant to CDC's mandate.
                    </P>
                    <HD SOURCE="HD3">• HL7 CDA® R2 Implementation Guide: National Health Care Surveys (NHCS), R1 STU Release 3.1—US Realm, January 6, 2022</HD>
                    <P>
                        <E T="03">URL: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=385.</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>
                         This standard is an HL7 Clinical Document Architecture (CDA) Implementation Guide for representing data extracted from provider systems as required by the Centers for Disease Control and Prevention's National Center for Health Statistics (CDC/NCHS) for the National Ambulatory Medical Care Survey (NAMCS) and the National Hospital Care Survey (NHCS). The implementation guide creates a standardized format to represent ambulatory, inpatient, and outpatient healthcare data; enables automation of the survey data collection process by using CDA to streamline the collection of data and increase the sample pool by allowing all providers who participate in the surveys to do so electronically; the IG also supports physician offices'/hospitals' ability to participate in the NCHS surveys by providing electronic files from their EHRs.
                    </P>
                    <HD SOURCE="HD3">• HL7 FHIR Vital Records Birth and Fetal Death Reporting 1.1.0—STU 1.1, October 10, 2023</HD>
                    <P>
                        <E T="03">URL: https://hl7.org/fhir/us/bfdr/.</E>
                    </P>
                    <P>This is a direct access link.</P>
                    <P>
                        <E T="03">Summary:</E>
                         This implementation guide (IG) defines a series of Health Level Seven (HL7®) Fast Healthcare Interoperability Resources (FHIR®) profiles on the Composition resource to represent electronic birth and fetal death reporting (BFDR). It includes the content of medical/health information on live births and fetal deaths for select State and Federal birth and fetal death reporting, as indicated in the 2003 Revision of the U.S. Standard Certificate of Live Birth and the 2003 Revision of the U.S. Standard Report of Fetal Death Additionally, it includes the content that is exchanged between EHR systems, jurisdictions, and the Centers for Disease Control and Prevention/National Center for Health Statistics (CDC/NCHS).
                    </P>
                    <HD SOURCE="HD3">• CMS Implementation Guide for Quality Reporting Document Architecture Category I Hospital Quality Reporting, Implementation Guide for 2024, Version 1.1, August 31, 2023</HD>
                    <P>
                        <E T="03">URL: https://ecqi.healthit.gov/sites/default/files/QRDA-HQR-2024-CMS-IG-v1.1-508.pdf.</E>
                    </P>
                    <P>This is a direct access link.</P>
                    <P>
                        <E T="03">Summary:</E>
                         This quality reporting document architecture (QRDA) guide contains CMS implementation guide to the HL7 Implementation Guide for CDA Release 2: Quality Reporting Document Architecture Category I, Release 1, Standard for Trial Use (STU) Release 5.3, US Realm, and any subsequent errata update, for the 2024 reporting period.
                    </P>
                    <HD SOURCE="HD3">• HL7 CDA® R2 Implementation Guide: Quality Reporting Document Architecture—Category I (QRDA I)—US Realm, STU 5.3 with errata, December 2022</HD>
                    <P>
                        <E T="03">URL: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=35.</E>
                    </P>
                    <P>This is a direct access link.</P>
                    <P>
                        <E T="03">Summary:</E>
                         A QRDA Category I report is an individual-patient-level quality report. Each report contains quality data for one patient for one or more quality measures, where the data elements in the report are defined by the particular measure(s) being reported on. A QRDA 
                        <PRTPAGE P="63658"/>
                        Category I report contains raw applicable patient data. When pooled and analyzed, each report contributes the quality data necessary to calculate population measure metrics. This two-volume implementation guide (IG) describes constraints on the Clinical Document Architecture Release 2 (CDA R2) header and body elements for Quality Reporting Document Architecture (QRDA) documents.
                    </P>
                    <HD SOURCE="HD3">• CMS Implementation Guide for Quality Reporting Document Architecture Category III, Eligible Clinicians Programs, Implementation Guide for 2024, Version 1.1, November 22, 2023</HD>
                    <P>
                        <E T="03">URL: https://ecqi.healthit.gov/sites/default/files/2024-CMS-QRDA-III-EC-IG-v1.1-508.pdf.</E>
                    </P>
                    <P>This is a direct access link.</P>
                    <P>
                        <E T="03">Summary:</E>
                         This QRDA guide contains CMS supplemental implementation guide to the HL7 CDA R2 Implementation Guide: Quality Reporting Document Architecture (QRDA III), Release 1—US Realm (September 2021) for the 2024 performance period. This is a normative release approved by American National Standards Institute (ANSI) and HL7. This HL7 base standard is referred to as the HL7 QRDA III R1.
                    </P>
                    <HD SOURCE="HD3">• HL7 CDA® R2 Implementation Guide: Quality Reporting Document Architecture (QRDA III), Release 1—US Realm (ANSI/HL7 Normative Release 1), September 2021</HD>
                    <P>
                        <E T="03">URL: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=286.</E>
                    </P>
                    <P>This is a direct access link.</P>
                    <P>
                        <E T="03">Summary:</E>
                         A QRDA Category III report is an aggregate quality report. Each report contains calculated summary data for one or more measures for a specified population of patients within a particular health system over a specific period of time. Data needed to generate QRDA Category III reports must be included in the collected QRDA Category I reports, as the processing entity will not have access to additional data sources. The QRDA Category III Implementation Guide directs implementers on how to construct QRDA Category III instances to report aggregated results for electronic clinical quality measures (eCQMs).
                    </P>
                    <HD SOURCE="HD2">Vocabulary Standards for Representing Electronic Health Information—45 CFR 170.207</HD>
                    <HD SOURCE="HD3">• Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT®), U.S. Edition, September 2023 Release</HD>
                    <P>
                        <E T="03">URL: 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>
                         This release contains 163 new active concepts specific to the US Extension. The September 2023 US Edition of SNOMED CT is based on the content published in the June 2023 SNOMED CT International Edition and includes any SNOMED CT COVID-19 Related Content published in the June 2023 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>
                    <HD SOURCE="HD3">• Logical Observation Identifiers Names and Codes (LOINC®) Database Version 2.76, a Universal Code System for Identifying Laboratory and Clinical Observations Produced by the Regenstrief Institute, Inc., September 18, 2023</HD>
                    <P>
                        <E T="03">URL: https://loinc.org/downloads/.</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>
                         LOINC version 2.76 is a Hotfix release only. No new concepts have been added.
                    </P>
                    <P>This Hotfix addresses issues discovered after the release of version 2.75 in August 2023. Version 2.76 includes updates to 196 concepts.</P>
                    <HD SOURCE="HD3">• RxNorm, a Standardized Nomenclature for Clinical Drugs Produced by the United States National Library of Medicine, December 4, 2023, Full Monthly Release</HD>
                    <P>
                        <E T="03">URL: 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="HD3">• CDC National Center of Immunization and Respiratory Diseases (NCIRD) Code Set (CVX)—Vaccines Administered, Updates Through September 29, 2023</HD>
                    <P>
                        <E T="03">URL: 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 either HL7 Version 2.3.1 or HL7 Version 2.5.1.
                    </P>
                    <HD SOURCE="HD3">• National Drug Code Directory (NDC)—Vaccine NDC Linker, Updates Through November 6, 2023</HD>
                    <P>
                        <E T="03">URL: 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 the CDC.
                    </P>
                    <HD SOURCE="HD2">Standards for Health Information Technology To Protect Electronic Health Information Created, Maintained, and Exchanged—45 CFR 170.210</HD>
                    <HD SOURCE="HD3">• Annex A: Federal Information Processing Standards (FIPS) Publication 140-2, Security Requirements for Cryptographic Modules, October 8, 2014</HD>
                    <P>
                        <E T="03">URL: https://web.archive.org/web/20150218170400/http://csrc.nist.gov/publications/fips/fips140-2/fips1402annexa.pdf</E>
                        .
                    </P>
                    <P>This is a direct access link.</P>
                    <P>
                        <E T="03">Summary:</E>
                         Federal Information Processing Standards Publication (FIPS 
                        <PRTPAGE P="63659"/>
                        PUB) 140-2, Security Requirements for Cryptographic Modules, specifies the security requirements that are to be satisfied by the cryptographic module utilized within a security system protecting sensitive information within computer and telecommunications systems (including voice systems). The standard provides four increasing, qualitative levels of security: Level 1, Level 2, Level 3, and Level 4. These levels are intended to cover the wide range of potential applications and environments in which cryptographic modules may be employed. The security requirements cover eleven areas related to the secure design and implementation of the cryptographic module.
                    </P>
                    <HD SOURCE="HD3">• Annex A: Approved Security Functions for FIPS PUB 140-2, Security Requirements for Cryptographic Modules, October 12, 2021</HD>
                    <P>
                        <E T="03">URL: https://csrc.nist.gov/files/pubs/fips/140-2/upd2/final/docs/fips1402annexa.pdf</E>
                        .
                    </P>
                    <P>This is a direct access link.</P>
                    <P>
                        <E T="03">Summary:</E>
                         Federal Information Processing Standards Publication (FIPS) 140-2, Security Requirements for Cryptographic Modules, specifies the security requirements that are to be satisfied by the cryptographic module utilized within a security system protecting sensitive information within computer and telecommunications systems (including voice systems). The standard provides four increasing, qualitative levels of security: Level 1, Level 2, Level 3, and Level 4. These levels are intended to cover the wide range of potential applications and environments in which cryptographic modules may be employed.
                    </P>
                    <HD SOURCE="HD2">United States Core Data for Interoperability—45 CFR 170.213</HD>
                    <HD SOURCE="HD3">• United States Core Data for Interoperability (USCDI), Version 4 (v4), October 2023 Errata</HD>
                    <P>
                        <E T="03">URL: 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 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>
                    <HD SOURCE="HD3">• HL7 FHIR® US Core Implementation Guide, Version 7.0.0—STU7, May 8, 2024</HD>
                    <P>
                        <E T="03">URL: https://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. It defines the minimum constraints on the FHIR resources to create the US Core Profiles. The elements, extensions, vocabularies, and value sets that SHALL be present are identified, and how they are used is defined. It also documents the minimum FHIR RESTful interactions for each US Core Profiles to access patient data. Establishing the “floor” of standards to promote interoperability and adoption through common implementation allows for further standards development evolution for specific use cases.
                    </P>
                    <HD SOURCE="HD3">• United States Public Health Profiles Library Implementation Guide. US Public Health Profiles Library 1.0.0—STU1, October 4, 2023</HD>
                    <P>
                        <E T="03">URL: https://build.fhir.org/ig/HL7/fhir-us-ph-common-library-ig/</E>
                        .
                    </P>
                    <P>This is a direct access link.</P>
                    <P>
                        <E T="03">Summary:</E>
                         The US Public Health Profiles Library (USPHPL) is a collection of reusable architecture and content profiles representing common public health concepts and patterns. It is intended as a complement to the US Core Implementation Guide (US Core) to ease implementation burden of healthcare organizations, electronic health record companies, public health agencies, and others involved in the US public health endeavor.
                    </P>
                    <HD SOURCE="HD3">• HL7® SMART App Launch Implementation Guide Release 2.2.0—STU 2.2, April 30, 2024</HD>
                    <P>
                        <E T="03">URL: https://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 Auth 2.0 for client applications to authorize, authenticate, and integrate with FHIR-based data systems.
                    </P>
                    <HD SOURCE="HD3">• HL7 FHIR Bulk Data Access IG, 2.0.0—STU 2 Ballot, November 26, 2021</HD>
                    <P>
                        <E T="03">URL: https://build.fhir.org/ig/HL7/bulk-data/</E>
                        .
                    </P>
                    <P>This is a direct access link.</P>
                    <P>
                        <E T="03">Summary:</E>
                         This implementation guide defines a standardized, FHIR based approach for exporting bulk data from a FHIR server to a pre-authorized client. This implementation guide is designed to support sharing any data that can be represented in FHIR. This means that the IG should be useful for such diverse systems as, “native” FHIR servers that store FHIR resources directly, EHR systems and population health tools implementing FHIR as an interoperability layer, and financial systems implementing FHIR as an interoperability layer.
                    </P>
                    <HD SOURCE="HD3">• HL7 CDS Hooks Release 2.0, August 23, 2022</HD>
                    <P>
                        <E T="03">URL: https://cds-hooks.hl7.org/</E>
                        .
                    </P>
                    <P>This is a direct access link.</P>
                    <P>
                        <E T="03">Summary:</E>
                         The CDS Hooks specification describes the RESTful APIs and interactions using JSON over HTTPS to integrate Clinical Decision Support (CDS) between CDS Clients (typically EHR Systems or other health information systems) and CDS Services.
                    </P>
                    <HD SOURCE="HD3">• SMART Health Cards Framework Version 1.4.0, June 15, 2023</HD>
                    <P>
                        <E T="03">URL: https://spec.smarthealth.cards/</E>
                        .
                    </P>
                    <P>This is a direct access link.</P>
                    <P>
                        <E T="03">Summary:</E>
                         This implementation guide provides a framework for “Health Cards”. The framework supports documentation of any health-related details that can be modeled with HL7 FHIR. This enables a consumer to receive COVID-19 Vaccination or Laboratory results and present these results to another party in a verifiable manner. Key use cases included conveying point-in-time infection status for return-to-workplace and travel.
                    </P>
                    <HD SOURCE="HD3">• HL7 FHIR SMART Health Cards: Vaccination and Testing Implementation Guide Version 1.0.0—STU 1, December 27, 2023</HD>
                    <P>
                        <E T="03">URL: https://build.fhir.org/ig/HL7/fhir-shc-vaccination-ig/</E>
                        .
                    </P>
                    <P>This is a direct access link.</P>
                    <P>
                        <E T="03">Summary:</E>
                         This FHIR Implementation Guide describes the FHIR contents of a SMART Health Card (SHC) for infectious disease vaccination records and laboratory testing status. This includes a minimal set of patient information (name and contact information) that are needed for this use case.
                    </P>
                    <HD SOURCE="HD3">• HL7 FHIR Subscriptions R5 Backport Implementation Guide Version 1.1.0—Standard for Trial Use, January 11, 2022</HD>
                    <P>
                        <E T="03">URL: https://hl7.org/fhir/uv/subscriptions-backport/STU1.1/</E>
                        .
                    </P>
                    <P>This is a direct access link.</P>
                    <P>
                        <E T="03">Summary:</E>
                         The Subscription R5 Backport Implementation Guide enables 
                        <PRTPAGE P="63660"/>
                        servers running versions of FHIR earlier than R5 to implement a subset of R5 Subscriptions in a standardized way. During the development of FHIR R5, the Subscriptions Framework has gone through a significant redesign. Many implementers have expressed a need for functionality from the FHIR R5 version of Subscriptions to be made available in FHIR R4. The goal of publishing this guide is to define a standard method of back-porting the R5 Subscriptions Framework for greater compatibility and adoption.
                    </P>
                    <HD SOURCE="HD3">
                        • HL7 FHIR® Unified Data Access Profiles (UDAP
                        <SU>TM</SU>
                        ) Security for Scalable Registration, Authentication, and Authorization Implementation Guide Release 1.0.0—STU 1 U.S., September 27, 2022
                    </HD>
                    <P>
                        <E T="03">URL: https://hl7.org/fhir/us/udap-security/.</E>
                    </P>
                    <P>This is a direct access link.</P>
                    <P>
                        <E T="03">Summary:</E>
                         This implementation guide describes how to extend oAuth 2.0 using UDAP workflows for both consumer-facing apps that implement the authorization code flow, and business-to-business (B2B) apps that implement the client credentials flow or authorization code flow. This guide covers automating the client application registration process and increasing security using asymmetric cryptographic keys bound to digital certificates to authenticate ecosystem participants. This guide also provides a grammar for communicating metadata critical to healthcare information exchange.
                    </P>
                    <HD SOURCE="HD3">• HL7 FHIR® Da Vinci—Payer Data Exchange (PDex) Implementation Guide: Version 2.0.0—STU2, January 6, 2024</HD>
                    <P>
                        <E T="03">URL: https://hl7.org/fhir/us/davinci-pdex/STU2/.</E>
                    </P>
                    <P>This is a direct access link.</P>
                    <P>
                        <E T="03">Summary:</E>
                         The Payer Data Exchange (PDex) Implementation Guide is provided for payers/health plans to enable them to create a Member's Health History using clinical resources (based on U.S. Core Profiles established from FHIR R4) which can be understood by providers and, if they choose to, committed to their Electronic Medical Records (EMR) System.
                    </P>
                    <HD SOURCE="HD3">• HL7 FHIR Da Vinci—Coverage Requirements Discovery (CRD) Implementation Guide, Version 2.0.1—STU 2, January 8, 2024</HD>
                    <HD SOURCE="HD3">
                        <E T="03">URL: https://hl7.org/fhir/us/davinci-crd/STU2/.</E>
                    </HD>
                    <P>This is a direct access link.</P>
                    <P>
                        <E T="03">Summary:</E>
                         The Da Vinci Coverage Requirements Discovery (CRD) Implementation Guide defines a workflow to allow payers to provide information about coverage requirements to healthcare providers through their provider systems at the time treatment decisions are being made. This will ensure that clinicians and administrative staff have the capability to make informed decisions and meet the requirements of the patient's insurance coverage.
                    </P>
                    <HD SOURCE="HD3">• HL7 FHIR Da Vinci—Documentation Templates and Rules (DTR) Implementation Guide, Version 2.0.1—STU 2, January 11, 2024</HD>
                    <P>
                        <E T="03">URL: https://hl7.org/fhir/us/davinci-dtr/STU2/.</E>
                    </P>
                    <P>This is a direct access link.</P>
                    <P>
                        <E T="03">Summary:</E>
                         The Da Vinci Documentation Templates and Rules (DTR) Implementation Guide provides a mechanism for payers to express their documentation requirements computably in a way that allows clinicians and other EHR users to navigate and quickly specify the needed information in a context-specific way. The guide allows rules to be written in a way that supports automatically extracting existing EHR information for review/confirmation and adjusting the information prompted for based on what data is already known or entered, minimizing impact on provider time, while expediting subsequent payer interactions.
                    </P>
                    <HD SOURCE="HD3">• HL7 FHIR Da Vinci—Prior Authorization Support (PAS) FHIR IG, Version 2.0.1—STU 2, December 1, 2023</HD>
                    <P>
                        <E T="03">URL: https://hl7.org/fhir/us/davinci-pas/STU2/.</E>
                    </P>
                    <P>This is a direct access link.</P>
                    <P>
                        <E T="03">Summary:</E>
                         The Da Vinci Prior Authorization Support (PAS) Implementation Guide enables direct submission of prior authorization requests from EHR systems using FHIR. The implementation guide also defines capabilities around the management of prior authorization requests, including checking the status of a previously submitted request, updating a previously submitted request, and canceling a request. Direct submission of prior authorization requests from the EHR can result in faster prior authorization decisions, reducing costs for both providers and payers and improving patient experience.
                    </P>
                    <HD SOURCE="HD3">• HL7 FHIR® Consumer Directed Payer Data Exchange (CARIN IG for Blue Button®) Implementation Guide, Version 2.0.0—STU 2, November 28, 2022</HD>
                    <P>
                        <E T="03">URL: https://hl7.org/fhir/us/carin-bb/.</E>
                    </P>
                    <P>This is a direct access link.</P>
                    <P>
                        <E T="03">Summary:</E>
                         This implementation guide describes the CARIN for Blue Button® Framework and Common Payer Consumer Data Set (CPCDS), providing a set of resources that payers can display to consumers via a FHIR API. The CARIN for Blue Button IG was defined by the CARIN Alliance to meet the requirements in the CMS Interoperability and Patient Access final rule for impacted payers to make available claims and encounter data via a Patient Access API. This IG is primarily used to exchange financial (claims and encounter) data, with some limited associated clinical data.
                    </P>
                    <HD SOURCE="HD3">
                        • 
                        <E T="03">HL7 FHIR Da Vinci—Payer Data Exchange (PDex) U.S. Drug Formulary Implementation Guide, Version 2.0.1—STU 2, December 1, 2023</E>
                    </HD>
                    <P>
                        <E T="03">URL: https://hl7.org/fhir/us/davinci-drug-formulary/STU2.0.1/.</E>
                    </P>
                    <P>This is a direct access link.</P>
                    <P>
                        <E T="03">Summary:</E>
                         This implementation guide defines a FHIR interface to a health insurer's drug formulary information for patients/consumers. The primary use cases for this FHIR interface enable consumers/members/patients to understand the costs and alternatives for drugs that have been prescribed, and to compare their drug costs across different insurance plans.
                    </P>
                    <HD SOURCE="HD3">• HL7 FHIR Da Vinci Payer Data Exchange (PDex) Plan Net Implementation Guide, Version 1.1.0—STU1.1 US, April 4, 2022</HD>
                    <P>
                        <E T="03">URL: https://hl7.org/fhir/us/davinci-pdex-plan-net/STU1.1/.</E>
                    </P>
                    <P>This is a direct access link.</P>
                    <P>
                        <E T="03">Summary:</E>
                         This implementation guide defines a FHIR interface to access information about a health insurer's insurance plans, their associated networks, and the organizations and providers that participate in these networks. Publication of this data through a standard FHIR-based API will enable third parties to develop applications through which consumers and providers can query the participants in a payer's network that may provide services that address their healthcare needs.
                    </P>
                    <HD SOURCE="HD1">VII. Response to Comments</HD>
                    <P>
                        Because of the large number of public comments normally received in response to 
                        <E T="04">Federal Register</E>
                         documents, we are not able to acknowledge or respond to them individually. We will consider all comments we receive by the date and time specified in the 
                        <E T="02">DATES</E>
                         section of this preamble, and when we proceed with a subsequent document, we will 
                        <PRTPAGE P="63661"/>
                        respond to the comments in the preamble of that document.
                    </P>
                    <HD SOURCE="HD1">VIII. 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 60-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 explicitly seek, and will consider, public comment on our assumptions as they relate to the PRA requirements summarized in this section. To comment on the collection of information or to obtain copies of the supporting statements and any related forms for the proposed paperwork collections referenced in this section, email your comment or request, including your address and phone number to 
                        <E T="03">sherrette.funn@hhs.gov,</E>
                         or call the Reports Clearance Office at (202) 690-6162. Written comments and recommendations for the proposed information collections must be directed to the OS Paperwork Clearance Officer at the above email address within 60 days.
                    </P>
                    <HD SOURCE="HD2">
                        A. Qualified Health Information Networks
                        <E T="01">
                            <SU>TM</SU>
                        </E>
                    </HD>
                    <P>We propose in § 172.301 to establish the information Applicant QHINs must submit in order to be Designated as a QHIN. We propose that an Applicant QHIN must submit: (1) a completed QHIN application; and (2) a signed copy of the Common Agreement. We note that the application may be updated over time and the most recent version will be available on ONC's and the RCE's website.</P>
                    <P>In § 172.701, we propose attestation submission requirements for QHINs and review and acceptance processes that ONC would follow for TEFCA attestations. In § 172.701(b), we propose that in order to be listed in the QHIN Directory described in proposed § 172.702, a QHIN would be required to submit to ONC an attestation affirming agreement with and adherence to the Trusted Exchange Framework and its adoption of the Common Agreement. We further propose in § 172.701(b) that a QHIN would be required to submit to ONC identifying information consisting of its name, address, city, State, zip code, and a hyperlink to its website. We also propose that the QHIN would be required to submit to ONC identifying information about its authorized representative including the representative's name, title, phone number, and email address.</P>
                    <P>We propose that a QHIN would also be required to provide documentation confirming its Designation as a QHIN. We also propose that a QHIN would be required to provide ONC with written notice of any changes to its identifying information provided in accordance with § 172.701 within 30 calendar days of the change(s) to its identifying information.</P>
                    <P>
                        We believe QHINs will face minimal burden in complying with the proposed application, attestation, and supporting documentation requirements. For the purposes of estimating the potential burden, at this time, we are estimating that 15 Applicant QHINs would apply and subsequently submit an attestation to ONC. We believe it will take approximately one hour on average for an applicant QHIN to submit a completed QHIN application. We believe it will also take approximately one hour on average for a QHIN to complete and submit to ONC their attestation and required documentation. We expect a general office clerk could complete these required responsibilities.
                        <SU>262</SU>
                        <FTREF/>
                         We welcome comments if interested parties believe more or fewer QHINs should be included in our estimate. We also welcome comments if interested parties believe more or less time should be included in our estimate.
                    </P>
                    <FTNT>
                        <P>
                            <SU>262</SU>
                             According to the May 2022 BLS occupational employment statistics, the mean hourly wage for Office Clerks, General (43-9061) is $19.78.
                        </P>
                    </FTNT>
                    <GPH SPAN="3" DEEP="164">
                        <GID>EP05AU24.003</GID>
                    </GPH>
                    <PRTPAGE P="63662"/>
                    <HD SOURCE="HD2">B. ONC-ACBs</HD>
                    <P>We propose in § 170.556(d)(7), new requirements for an ONC-ACB to report specific information to ONC when a developer fails to timely complete an approved corrective action plan (CAP). This proposal would apply to an identified non-conformity with respect to any Program requirement codified in subpart D for which an ONC-ACB has responsibilities under § 170.523. Under this proposal in § 170.556(d)(7), an ONC-ACB would be required to notify the National Coordinator when an ONC-ACB's requirement to initiate suspension procedures is triggered by the developer's failure to engage (successfully or failure to engage at all, as applicable) with the CAP process for a non-conformity to a Maintenance of Certification requirement.</P>
                    <P>We propose in § 170.556(d)(7)(ii) that an ONC-ACB must report certain information to ONC when a developer fails to submit an approved CAP or to complete an approved CAP with respect to any Program requirement codified in subpart D for which an ONC-ACB has responsibilities under § 170.523. We propose the ONC-ACBs would report the information specified in § 170.523(x) to the National Coordinator pursuant to the requirements in § 170.556(d)(7)(i) and must notify the developer immediately when an ONC-ACB begins the notification procedures in paragraph § 170.556(d)(7)(i).</P>
                    <P>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 to the PRA under 5 CFR 1320.3(c). We continue to estimate fewer than 10 ONC-ACB respondents for all of the regulatory “collection of information” requirements under part 170 of Title 45. We welcome comments on this conclusion and our supporting rationale for this conclusion.</P>
                    <HD SOURCE="HD1">IX. Regulatory Impact Analysis</HD>
                    <HD SOURCE="HD2">A. Statement of Need</HD>
                    <P>This proposed rule is necessary to meet our statutory responsibilities under the Cures Act and to advance HHS policy goals to promote interoperability and mitigate burden for health IT developers and users. Policies that could result in monetary costs for health IT developers and users include: (1) updates to ONC Certification Criteria for Health IT; and (2) developing the Patient, Provider, and Payer APIs.</P>
                    <P>While much of this proposed 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, Dynamic Client Registration Protocol 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 proposed rule will remove barriers to interoperability and EHI exchange, which will greatly benefit health care providers and patients.</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 consistent with our policy goals. We believe our policies take the necessary steps to fulfill the mandates specified in the PHSA, as amended by the HITECH Act and the Cures Act, in the least burdensome way. We welcome comments on our assessment and any alternatives we should consider.</P>
                    <HD SOURCE="HD2">C. Overall Impact</HD>
                    <HD SOURCE="HD3">1. Executive Orders 12866 and 13563—Regulatory Planning and Review Analysis</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. 96354), 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), and the Executive Order 13132 on Federalism (August 4, 1999).</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 action(s) and/or with significant effects as per section 3(f)(1) ($200 million or more in any 1 year). Based on our estimates, this rulemaking is significant per section 3(f)(1) as measured by the $200 million or more in any 1-year threshold.</P>
                    <HD SOURCE="HD3">a. Costs and Benefits</HD>
                    <P>
                        We have estimated the potential monetary costs and benefits of this proposed rule for health IT developers, health care providers, patients, and the Federal Government (
                        <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 80. The impact analysis primarily assesses the costs and benefits of proposed changes to the Program. The Program, as described elsewhere in this 
                        <PRTPAGE P="63663"/>
                        rule, is voluntary. Developers who present their technology for certification do so for varied reasons, including so their users can meet Federal requirements and to demonstrate conformance with federally adopted standards. However, we recognize there are real costs associated with any changes to certified health IT and requirements for developers of certified health IT to maintain certification. We estimate these costs to the best of our ability, examining the development tasks and burden associated with each proposal. We also estimate and articulate the expected benefits of these proposals. Whereas we estimate the costs associated with development tasks for developers of certified health IT, benefits can be more far reaching—affecting developers directly through standards harmonization and clear processes for technology development as well as health care providers, patients, and payers who are end-users of the technology and whose use derives direct benefit through improvements to electronic health information exchange, access to electronic health information, and automation of clinical and administrative processes. Although participation in the Program is voluntary, we believe that requirements to use certified health IT by Federal programs, to adopt health IT standards, and exchange and make data available to health care providers, patients, and payers provide levers to technology developers to present their IT for certification. Program requirements are meant to harmonize health IT development and promote interoperability through common health IT standards and rules of information exchange and access. The benefits described more thoroughly, below, such as those for interoperability, as we have described in prior rulemaking, such as the ONC Cures Final Rule (85 FR 25642), are derived from more universal adoption of these standards and rules that enable data to be electronically recorded, stored, exchanged, and accessed more harmoniously. These actions may remove artificial barriers to information exchange and access that often result in the duplication of diagnostic and laboratory testing, fragmented care, missing medical record information, and less consumer choice in the healthcare market.
                        <E T="51">263 264</E>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>263</SU>
                             Jones SS, Rudin RS, Perry T, Shekelle PG. Health information technology: an updated systematic review with a focus on meaningful use. Ann Intern Med. 2014 Jan 7;160(1):48-54. doi: 10.7326/M13-1531. PMID: 24573664.
                            <E T="03">https://pubmed.ncbi.nlm.nih.gov/24573664/.</E>
                        </P>
                        <P>
                            <SU>264</SU>
                             Everson J, Adler-Milstein J. Sharing information electronically with other hospitals is associated with increased sharing of patients. Health Serv Res. 2020 Feb;55(1):128-135. doi: 10.1111/1475-6773.13240. Epub 2019 Nov 12. PMID: 31721183; PMCID: PMC6980958.
                            <E T="03">https://pubmed.ncbi.nlm.nih.gov/31721183/.</E>
                        </P>
                    </FTNT>
                    <P>
                        Our cost calculations quantify health IT developers' time and effort to implement these policies through new development and administrative activities. Our cost estimates use publicly available data and information, if available, to estimate time and effort. We also, where applicable, carry forward cost estimates from prior rulemakings to be consistent in time and effort estimates. Novel cost estimates also use a mix of subject matter expertise and appropriate proxies to quantify costs. We note these methods and sources in the tables. 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 that provide acute, inpatient care and over 1 million clinicians who provide outpatient care to all Americans. Official statistics show that nearly all U.S. non-Federal acute care hospitals and the vast majority of outpatient physicians use certified health IT.
                        <E T="51">265 266</E>
                        <FTREF/>
                         These policies affect the technology that all these health care providers use.
                    </P>
                    <FTNT>
                        <P>
                            <SU>265</SU>
                             
                            <E T="03">https://www.healthit.gov/data/quickstats/national-trends-hospital-and-physician-adoption-electronic-health-records.</E>
                        </P>
                        <P>
                            <SU>266</SU>
                             
                            <E T="03">https://www.healthit.gov/data/quickstats/office-based-physician-electronic-health-record-adoption.</E>
                        </P>
                    </FTNT>
                    <P>However, we are clear in our analysis and estimates of costs, below, that we do not assess the costs on health care providers to use this technology. This may include changes to how the provider electronically documents information in the medical record, changes to workflow, or how technology is implemented by a provider and at a particular health care delivery site. The costs estimate the expected burden on health IT developers to develop and provide the revised technology to their users, not the expected burden on users to use the revised technology, which is considered out of scope for this rulemaking, as we do not require the use of the technology, just the development of the technology. Other Federal agencies do require, as of their official rulemaking and policymaking, the use of certified health IT to participate in programs or receive payment for treating a patient. The costs and benefits of these requirements on health care providers to adopt and use certified health IT are estimated and explained in those rules' regulatory impact analysis. For example, the CMS Interoperability and Prior Authorization final rule (89 FR 8758) describes how the implementation of electronic, standards-based prior authorization and other information exchange integrated into the EHR can reduce burden on patients, providers, and payers resulting in an estimated $15 billion of savings over ten years. The proposals described below will help establish and build these standards and other technology into certified health IT for use by health care providers and others to achieve these estimated savings.</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. We request comment on the increase in software licensing costs and other fees resulting from these proposals and if ongoing licensing costs and fees already consider the costs of meeting new regulations and certification requirements (
                        <E T="03">i.e.,</E>
                         some or none of the estimated costs of this proposed rulemaking would be passed on to technology end-users.)
                    </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 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 
                        <PRTPAGE P="63664"/>
                        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 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 technology used by the providers who give care to a vast majority of Americans. Nearly all emergency room visits, hospital stays, and regular check-ups are documented and managed using certified health IT. These 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 proposed in this proposed 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 numerous digital health and technology companies to connect and integrate with EHRs to provide healthcare and other services to app and digital services users.
                        <SU>267</SU>
                        <FTREF/>
                         It is also speculative to quantify benefits for specific stakeholders because benefits associated with many of ONC's policies, which advance interoperability, do not necessarily accrue to stakeholders making the investments in developing and implementing the technologies. Benefits related to interoperability are spread across the healthcare ecosystem and can be considered a societal benefit. We have sought to describe benefits for each of the specific policies, and we welcome comments on how to quantify these benefits across a variety of stakeholders.
                    </P>
                    <FTNT>
                        <P>
                            <SU>267</SU>
                             Wesley Barker, Natalya Maisel, Catherine E Strawley, Grace K Israelit, Julia Adler-Milstein, Benjamin Rosner, A national survey of digital health company experiences with electronic health record application programming interfaces, Journal of the American Medical Informatics Association, Volume 31, Issue 4, April 2024, Pages 866-874, 
                            <E T="03">https://doi.org/10.1093/jamia/ocae006</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>268</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>268</SU>
                             May 2022 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>269</SU>
                        <FTREF/>
                         However, achieving interoperability is a function of several 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>269</SU>
                             Nir Menachemi, Saurabh Rahurkar, Christopher A Harle, Joshua R Vest, The benefits of health information exchange: an updated systematic review, Journal of the American Medical Informatics Association, 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>270</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>271</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>270</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>271</SU>
                             
                            <E T="03">See</E>
                             U.S. Department of Health and Human Services, Office of the Assistant Secretary for Planning and Evaluation (ASPE), Guidelines for Regulatory Impact Analysis, at 28-30 (2016), available at 
                            <E T="03">https://aspe.hhs.gov/reports/guidelines-regulatory-impact-analysis.</E>
                        </P>
                    </FTNT>
                    <P>
                        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>272</SU>
                        <FTREF/>
                         These wage estimates are a national average and we do not consider regional wage variation in our estimates. We also do not consider possible variation in the average wages for software developers in health care IT positions versus IT positions, more generally, which the BLS wage estimate is based upon. 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 welcome comments on our methodology for estimating labor costs, including the effects of any regional or IT sector wage variation on our estimates.
                    </P>
                    <FTNT>
                        <P>
                            <SU>272</SU>
                             May 2022 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 2015 Edition Cures Update and the estimated number of developers that will participate in the future and the number of products these developers will certify.</P>
                    <P>
                        We recognize that certification is ongoing for new requirements finalized 
                        <PRTPAGE P="63665"/>
                        in ONC's HTI-1 Final Rule and ONC Cures Act Final Rule and the number of health IT developers certifying products to these requirements is subject to change. The figures for 2015 Edition in Table 3A reflect certifications through 2022 for products certified to 2015 Edition and 2015 Edition Cures Update requirements. Counts, therefore, do not account for all certificates as of the publication of this proposed rulemaking.
                    </P>
                    <P>
                        These estimates are based on observed and expected conformance to the Program requirements, market consolidation, industry trends and business decisions by participating developers, and other voluntary and involuntary withdrawals from the Program. We understand that there are possible effects from regulation on market competition. Regulatory changes can lead to withdrawal from the Program. Participation in the Program is voluntary and participants face a mix of incentives to test and certify their products. Some health IT developers participate to ensure their users, who must meet Federal requirements or receive incentives to adopt and use certified health IT, have certified technology that meets the most current requirements. Some others, like new entrants, certify to demonstrate conformance and adoption of specific standards and functionalities, despite not having a large user base. Over time, as the table, below, shows, the overall number of developers and certified products have gone down. This is due to both market dynamics (
                        <E T="03">e.g.,</E>
                         developers stop production or close due to competition) and regulatory changes (
                        <E T="03">e.g.,</E>
                         standards and functional requirements are too costly to adopt.) Market dynamics are expected as users select specific technology and some companies close due to lack of business. Some attrition may be due to the high ceiling to meet certain requirements, but our data show that few participants with a certain number of customer/technology users leave the program due to regulatory changes alone. Developers with low market share or no known users may leave the Program despite remaining in operation. We know of no known instance where a developer voluntarily left the program due to regulatory changes, leaving many technology users without certified health IT.
                    </P>
                    <P>The number of participants and range of products in the Program remain diverse, providing choice to customers and ensuring competition in the market for certified health IT. Notably, changes to the program over time, like the focus on certifying “health IT modules” versus “EHRs” has created flexibility for new entrants to participate in the program and introduced more choice to technology users who may shop for a wider array of certified products. In Table 3A 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%, respectively.</P>
                    <GPH SPAN="3" DEEP="125">
                        <GID>EP05AU24.004</GID>
                    </GPH>
                    <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 health IT 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>As shown in Table 3B, through 2022, 510 health IT developers certified 758 products since the start of 2015 Edition certification. As of the end of 2022, 435 health IT developers certified 590 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 22% decrease in 2015 Edition certified products, overall. As of the end of 2021, 414 health IT developers certified 569 products with active certificates for the 2015 Edition or 2015 Edition Cures Update. Compared to the end of 2022, this represents a 1-year 5% increase in the number of developers of certified health IT and 4% increase in number of certified products from the end of 2021.</P>
                    <GPH SPAN="3" DEEP="138">
                        <PRTPAGE P="63666"/>
                        <GID>EP05AU24.005</GID>
                    </GPH>
                    <P>
                        However, we expect, as we modeled in the HTI-1 Final Rule,
                        <SU>273</SU>
                        <FTREF/>
                         that new requirements finalized by that rulemaking may lead to some exits from the Program. We assume this modeled attrition estimated for the HTI-1 Final Rule will affect the estimated number of developers of certified health IT and number of certified products that will be required to meet requirements proposed in this rulemaking. For the HTI-1 Final Rule, we estimated an 11% decrease in the number of health IT developers and a 12% decrease in the number of certified products.
                        <SU>274</SU>
                        <FTREF/>
                         As shown in Table 4, we use this expected attrition to estimate the numbers of developers and products that would be required to meet the proposed requirements, consistent with what we forecasted for the HTI-1 Final Rule. We do not estimate additional attrition resulting from this rule, but rather carry forward the estimated number of developers and products we expect will participate in the Program at the time when these proposed policies are required to be met. We estimate that 387 developers of certified health IT and 521 certified products will be impacted by this rulemaking. These estimates will be used throughout this RIA to model estimated costs and benefits. We request comment on the quantification of attrition from the Program that may result from these proposed policies.
                    </P>
                    <FTNT>
                        <P>
                            <SU>273</SU>
                             
                            <E T="03">https://www.federalregister.gov/d/2023-28857/p-2446.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>274</SU>
                             
                            <E T="03">https://www.federalregister.gov/documents/2024/01/09/2023-28857/health-data-technology-and-interoperability-certification-program-updates-algorithm-transparency-and. See</E>
                             Regulatory Impact Analysis.
                        </P>
                    </FTNT>
                    <GPH SPAN="3" DEEP="90">
                        <GID>EP05AU24.006</GID>
                    </GPH>
                    <HD SOURCE="HD3">Number of End Users That Might Be Impacted by ONC's Proposed 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 Medicare Promoting Interoperability Program and the Promoting Interoperability performance category under MIPS).</P>
                    <P>
                        One limitation of this approach is that we are unable to account for the impact of our provisions on users of certified health IT that were ineligible or did not participate in the CMS EHR Incentive Programs or current Medicare programs (
                        <E T="03">e.g.,</E>
                         the Medicare Promoting Interoperability Program). For example, in 2017, 78% of home health agencies and 66% of skilled nursing facilities reported adopting an EHR.
                        <SU>275</SU>
                        <FTREF/>
                         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>
                    <FTNT>
                        <P>
                            <SU>275</SU>
                             
                            <E T="03">https://www.healthit.gov/data/data-briefs/electronic-health-record-adoption-and-interoperability-among-us-skilled-nursing.</E>
                        </P>
                    </FTNT>
                    <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 and CMS National Downloadable File of Doctors and Clinicians provides a current accounting of Medicare-participating hospitals and practice locations. 
                        <E T="51">276 277</E>
                        <FTREF/>
                         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.
                        <E T="51">278 279</E>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>276</SU>
                             
                            <E T="03">https://data.cms.gov/provider-characteristics/hospitals-and-other-facilities/provider-of-services-file-hospital-non-hospital-facilities.</E>
                        </P>
                        <P>
                            <SU>277</SU>
                             
                            <E T="03">https://data.cms.gov/provider-data/dataset/mj5m-pzi6.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>278</SU>
                             
                            <E T="03">https://www.healthit.gov/data/quickstats/national-trends-hospital-and-physician-adoption-electronic-health-records.</E>
                        </P>
                        <P>
                            <SU>279</SU>
                             
                            <E T="03">https://www.healthit.gov/data/quickstats/office-based-physician-electronic-health-record-adoption.</E>
                        </P>
                    </FTNT>
                    <PRTPAGE P="63667"/>
                    <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 in 85 FR 25642, we assume that one-third of estimated costs will be passed on to hospitals and the remaining amount on to clinician practices.
                        <SU>280</SU>
                        <FTREF/>
                         This estimate is based off an analysis of the proportion of Medicare EHR Incentive Program dollars that went to eligible hospitals versus eligible professionals.
                        <SU>281</SU>
                        <FTREF/>
                         We found that one-third of those program dollars were paid to hospitals, representing the disproportionate cost of health IT investments by a single hospital versus a single clinician. Table 5 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 $69,203 on average additional costs associated with implementing technology that adopt these policies. The average clinician practice site could be expected to face up to $2,250 on 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. To the extent that the increase in prices is large, the pass-through of costs onto consumers might decrease the quantity of care demanded. Given the below estimates for per provider costs, which could subsequently be defrayed across patients within the system, ONC does not believe this additional market distortion is likely to produce a substantial impact on the expected costs of the rule.
                    </P>
                    <FTNT>
                        <P>
                            <SU>280</SU>
                             
                            <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>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>281</SU>
                             
                            <E T="03">https://www.cms.gov/medicare/regulations-guidance/promoting-interoperability-programs.</E>
                        </P>
                    </FTNT>
                    <GPH SPAN="3" DEEP="84">
                        <GID>EP05AU24.007</GID>
                    </GPH>
                    <P>These costs are not expected to be borne at once. Requirements from this proposed 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 choose to assume a similar distribution for benefits as we propose for costs.</P>
                    <HD SOURCE="HD3">1. The United States Core Data for Interoperability Standard (USCDI) v4</HD>
                    <P>The USCDI standard in § 170.213 is a baseline set of data that can be commonly exchanged across care settings for a wide range of uses. Certain certification criteria in § 170.315 currently require the use of the USCDI standard in § 170.213. We propose to update the USCDI standard in § 170.213 by adding USCDI v4. We propose to add USCDI v4 in § 170.213(c) and incorporate it by reference in § 170.299. We propose that as of January 1, 2028, any Health IT Modules seeking certification to certification criteria referencing § 170.213 would need to be capable of exchanging the data elements that the USCDI v4 comprises.</P>
                    <P>Additionally, we propose that for purposes of the Program, the adoption of USCDI v3 expires on January 1, 2028. We propose that, for a health IT module certified to a criterion in § 170.315 that references a version of the USCDI standard adopted in § 170.213 that is expired, a health IT developer must update the module to a version of the standard that is not expired and provide the updated version to their customers according to the expiration date or dates defined for that standard in order to maintain certification of that Health IT Module as described in § 170.315. The following certification criteria currently reference the USCDI standard via cross-reference to § 170.213:</P>
                    <P>
                        • “Care coordination—Transitions of care—Create” (§ 170.315(b)(1)(iii)(A)(
                        <E T="03">1</E>
                        ) and (
                        <E T="03">2</E>
                        ));
                    </P>
                    <P>
                        • “Care coordination—Clinical information reconciliation and incorporation—Reconciliation” (§ 170.315(b)(2)(iii)(D)(
                        <E T="03">1</E>
                        )-(
                        <E T="03">3</E>
                        ));
                    </P>
                    <P>
                        • “Decision support interventions—Decision support configuration” (§ 170.315(b)(11)(ii) (A) and (B), and (iv)(A)(
                        <E T="03">5</E>
                        )-(
                        <E T="03">13</E>
                        ));
                    </P>
                    <P>
                        • “Patient engagement—View, download, and transmit to 3rd party—View” (§ 170.315(e)(1)(i)(A)(
                        <E T="03">1</E>
                        ) and (
                        <E T="03">2</E>
                        ), and (iii));
                    </P>
                    <P>• “Transmission to public health agencies—electronic case reporting” (§ 170.315(f)(5)(i)(C)(2)(i))—Referenced until December 31, 2025;</P>
                    <P>
                        • “Design and performance—Consolidated CDA creation performance” (§ 170.315(g)(6)(i)(A) and (B));
                        <PRTPAGE P="63668"/>
                    </P>
                    <P>
                        • “Design and performance—Application access—all data request—Functional requirements” (§ 170.315(g)(9)(i)(A)(
                        <E T="03">1</E>
                        ) and (2)); 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>If we finalize our proposal, all the above criteria, except for “Transmission to public health agencies—electronic case reporting”, whose reference expires December 31, 2025, would refer to USCDI v4.</P>
                    <HD SOURCE="HD3">Costs</HD>
                    <P>The USCDI v4 adds one new data class and 20 new data elements that were not in USCDI v3. This will require updates to the Consolidated Clinical Document Architecture (C-CDA) standard, the FHIR US Core Implementation Guide, and updates to the certification criteria listed above. We have estimated the proposed cost to health IT developers to add support for the additional data classes and data elements in USCDI v4 in C-CDA, and to make the necessary updates to the affected certification criteria. Both the lower and upper bound estimates in Table 6 assume 50% less effort to update technology to include new data elements introduced in USCDI version 4 compared to USCDI version 3. For the HTI-1 Final Rule (89 FR 1214), we estimated that up to 3,600 hours and as few as 1,800 hours would be needed to update technology from version 1 to version 3. These estimates are detailed in Tables 6 and 7 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 6 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 v4 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 7.</P>
                    <P>2. We estimate that 339 products certified by 263 developers will be affected by our proposal. These estimates are a subset of the total estimated health IT developers and certified products we estimated above.</P>
                    <P>We estimate that, in total, 387 health IT developers will certify 521 health IT products impacted by this proposal. However, not all these developers and products certify to USCDI applicable certification criteria and need to meet the USCDI update requirements. As of the end of 2022, 68% of developers and 65% of products certified to one of the certification criteria that cross-reference the USCDI standard in § 170.213, 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 7, we also applied separate modifiers for individual certification criteria, calculated from an analysis of certificates through 2022. This allows us to more accurately assess USCDI update costs for individual certification criteria.</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>
                    <BILCOD>BILLING CODE 4150-45-P</BILCOD>
                    <GPH SPAN="3" DEEP="626">
                        <PRTPAGE P="63669"/>
                        <GID>EP05AU24.008</GID>
                    </GPH>
                    <GPH SPAN="3" DEEP="487">
                        <PRTPAGE P="63670"/>
                        <GID>EP05AU24.009</GID>
                    </GPH>
                    <GPH SPAN="3" DEEP="428">
                        <PRTPAGE P="63671"/>
                        <GID>EP05AU24.010</GID>
                    </GPH>
                    <BILCOD>BILLING CODE 4150-45-C</BILCOD>
                    <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 certification 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 $115,038 to $230,076 per product. The cost to make updates to individual certification criteria to support the new data classes and elements range from $12,782 to $38,346 per product. Therefore, assuming 333 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 $62 million to $149 million. This would be a one-time cost to developers per product that is certified to the specified certification criteria and would not be perpetual.</P>
                    <HD SOURCE="HD3">Benefits</HD>
                    <P>
                        We believe this proposal would benefit health care providers, patients, and the health IT industry as a whole. The USCDI comprises a core set of structured and unstructured data needed to support patient care and facilitate patient access using health IT; establishes a consistent baseline of harmonized data elements that can be broadly reused across use cases, including those outside of patient care and patient access; and will expand over time via a predictable, transparent, and collaborative process, weighing both anticipated benefits and industry-wide impacts. The additional data elements in USCDI v4 expand the baseline set of data available for health information exchange and thus provide more comprehensive health data for both providers and patients.
                        <SU>282</SU>
                        <FTREF/>
                         We expect the resulting improvements to interoperable exchange of health information to significantly benefit providers and patients and improve the quality healthcare provided. In addition, we believe the increased availability of the additional data elements in USCDI v4 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 welcome comments on potential approaches to quantifying these benefits.
                    </P>
                    <FTNT>
                        <P>
                            <SU>282</SU>
                             
                            <E T="03">https://www.healthit.gov/sites/default/files/page/2023-07/Standards_Bulletin_2023-2.pdf.</E>
                        </P>
                    </FTNT>
                    <PRTPAGE P="63672"/>
                    <HD SOURCE="HD3">2. SMART App Launch 2.2</HD>
                    <P>
                        We propose to adopt SMART App Launch version 2.2. SMART App Launch version 2.0 is the most recently adopted version for use in the ONC certification program in the HTI-1 Final Rule (89 FR 1291 through 1296). Version 2.2 adds important new enhancements and features that improve upon version 2.0. However, we do not believe the adoption of the new enhancements will require additional burden beyond current program requirements to implement. We believe the effort to update health IT modules to the standard version will be 
                        <E T="03">de minimis.</E>
                         We request public comment on the effort needed to update to the new standard version.
                    </P>
                    <HD SOURCE="HD3">3. User-Access Brands and Endpoints</HD>
                    <P>In the ONC HTI-1 Final Rule, we finalized requirements in § 170.404(b)(2) that for all Health IT Modules certified to § 170.315(g)(10, Certified API Developers must publish certain service base URLs and related organization details in a standardized FHIR format (89 FR 1285 through 1290). Currently, user-access brands (Brands) is a sub-specification in the HL7 FHIR SMART Application Launch Framework Implementation Guide Release 2.2.0 (SMART v2.2 Guide). Brands provides guidelines for API providers to publish “Brands” associated with their FHIR endpoints that apps can collect and present to users. Each Brand can include information like organization name, location, identifier, patient portal details, FHIR API Endpoint, and more. These Brands are assembled in FHIR “Bundle” format, and these Bundles can made available in two ways: by FHIR servers including a link in their “.well-known/smart-configuration” metadata file, or through vendor-consolidated Brand Bundles that are openly published. The specification is very similar to the service base URLs requirement finalized in the HTI-1 Final Rule, and we believe the effort to adopt Brands will be de minimis. Our proposal to adopt Brands, in section III.B.3, will align with industry practice and standards, ensuring the service base URL requirements remain in line with best development practice. We request public comment on the additional effort beyond current requirements needed to adopt PAB.</P>
                    <HD SOURCE="HD3">4. Standards for Encryption and Decryption of Electronic Health Information</HD>
                    <P>We propose to adopt the October 12, 2021, version of Annex A of the FIPS Publication 140-2 in § 170.210(a)(3).</P>
                    <P>Adopting the October 12, 2021, version of Annex A of the FIPS Publication 140-2 in § 170.210(a)(3) would implicate three certification criteria that reference standards in § 170.210(a):</P>
                    <P>• § 170.315(d)(7) End-user device encryption, which we propose to rename “Health IT encryption”;</P>
                    <P>• § 170.315(d)(9) Trusted connection; and</P>
                    <P>• § 170.315(d)(12) Encrypt authentication credentials, which we propose to rename “Protect stored authentication credentials”.</P>
                    <P>
                        Since the finalization of the 2015 Edition Final Rule that adopted the October 8, 2014 version of Annex A of FIPS 140-2 in § 170.210(a)(2), encryption techniques and security best practices have continued to advance. The National Institute of Standards and Technology (NIST) has published several updated versions of Annex A of the FIPS Publication 140-2.
                        <SU>283</SU>
                        <FTREF/>
                         FIPS 140-2 specifies the security requirements that will be satisfied by a cryptographic module, providing four increasing, qualitative levels intended to cover a wide range of potential applications and environments.
                        <SU>284</SU>
                        <FTREF/>
                         Adopting the, October 12, 2021, version of Annex A of the FIPS Publication 140-2 in § 170.210(a)(3) will help ensure patients' data are protected and cybersecurity risks are mitigated.
                        <SU>285</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>283</SU>
                             
                            <E T="03">See</E>
                             pages 4-6 of the October 12, 2021 version of Annex A for a revision history of the standard. Available at: 
                            <E T="03">https://csrc.nist.gov/csrc/media/publications/fips/140/2/final/documents/fips1402annexa.pdf.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>284</SU>
                             
                            <E T="03">https://csrc.nist.gov/pubs/fips/140-2/upd2/final.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>285</SU>
                             
                            <E T="03">https://davidhoglund.typepad.com/files/white-paper---fips-in-medical-environments-0919.pdf.</E>
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Costs</HD>
                    <P>This proposal updates the standard referenced by § 170.315(d)(7), (d)(9), and (d)(12) to include an updated set of encryption algorithms identified by the National Institute of Standards and Technology (NIST) as an approved security function in Annex A of the Federal Information Processing Standards (FIPS) Publication 140-2, Security Requirements for Cryptographic Modules, October 8, 2014. The proposed change updates the standards referenced and does not change the functional requirements to test and certify the aforementioned certification criteria. We estimate effort to be de minimis for certified health IT developers, since the proposal does not functionally change how developers must meet the certification criteria's requirements.</P>
                    <HD SOURCE="HD3">5. Minimum Standards for 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). As we stated in the HTI-1 Final Rule, 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 (89 FR 1224). 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. While minimum standard code sets update frequently, perhaps several times in a single year, these updates are confined to concepts within the code system, not substantive changes to the standards themselves. We do not assess the burden to voluntarily adopt the updated code sets.</P>
                    <HD SOURCE="HD3">6. New Imaging Requirements for Health IT Modules</HD>
                    <P>We propose to revise the certification criteria found at “transitions of care” in § 170.315(b)(1); “application access—all data request” in § 170.315(g)(9); and “standardized API for patient and population services” in § 170.315(g)(10) to include certification requirements to support capturing and documenting hyperlinks to diagnostic imaging. We also propose to revise the certification criterion “view, download, and transmit to 3rd party” in § 170.315(e)(1) to add functional support for (a) viewing and direct download of diagnostic and lower quality images and (b) inclusion of a hyperlink to those diagnostic images in either a downloaded or transmitted Continuity of Care Document (CCD). The view and download functionalities must be accessible to the patient through the same internet-based technology as the other functionalities of § 170.315(e)(1).</P>
                    <P>
                        We are not, however, proposing a specific standard associated with the support of this functionality, and we note that this requirement can be met with a context-sensitive link to an external application which provides access to images and their associated narrative. A Health IT Module certified to these certification criteria is not required to support a specific standard. We believe that this proposal will promote more consistent access to images for providers.
                        <PRTPAGE P="63673"/>
                    </P>
                    <HD SOURCE="HD3">Costs</HD>
                    <P>The proposed revisions to §§ 170.315(b)(1), 170.315(g)(9), 170.315(g)(10), and 170.315(e)(1) require modifications to the currently adopted certification criteria to support capturing and documenting hyperlinks to diagnostic imaging and view and download of the diagnostic images by patients. These tasks have their own levels of effort, and their estimates are detailed in Tables 8 and 9 below and are based on the following assumptions:</P>
                    <P>1. Health IT developers will use the same labor costs and data models. Table 8 shows the estimated labor costs per product to modify § 170.315(b)(1), § 170.315(g)(9), § 170.315(g)(10), and § 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 9.</P>
                    <P>2. We estimate that 330 products certified by 256 developers will be affected by our proposal. These estimates are a subset of the total estimated number of health IT developers and certified products we estimated above.</P>
                    <P>The estimate of 330 products certified by 256 developers is derived as follows. We estimate that, in total, 387 health IT developers will certify 521 health IT products impacted by this rulemaking. However, not all these developers certify all of these products to § 170.315(b)(1), § 170.315(g)(9), § 170.315(g)(10), and § 170.315(e)(1) certification criteria and need to meet the proposed requirements. As of the end of 2022, 60% of developers and 53% of products certified to § 170.315(b)(1); 56% of developers and 50% of products certified to § 170.315(g)(9); 47% of developers and 43% of products certified to § 170.315(g)(10); and 53% of developers and 46% of products certified to § 170.315(e)(1). We, then, calculated the percentage of developers and products that certify to any of the four certification criteria to estimate the total of products and developments impacted by this proposal overall. We applied these modifiers 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 certification 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 $127.82.</P>
                    <BILCOD>BILLING CODE 4150-45-P</BILCOD>
                    <GPH SPAN="3" DEEP="493">
                        <PRTPAGE P="63674"/>
                        <GID>EP05AU24.011</GID>
                    </GPH>
                    <GPH SPAN="3" DEEP="153">
                        <GID>EP05AU24.012</GID>
                    </GPH>
                    <PRTPAGE P="63675"/>
                    <BILCOD>BILLING CODE 4150-45-C</BILCOD>
                    <P>The cost to a health IT developer to modify § 170.315(b)(1), § 170.315(g)(9), § 170.315(g)(10), and § 170.315(e)(1) for their Health IT Modules would range from $52,716 to $134,908 per product, on average. Therefore, assuming 330 products overall and a labor rate of $127.82 per hour, we estimate that the total cost to all health IT developers would, on average, would range from $17.4 million to $44.5 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>The benefits of these modifications are not quantifiable at this time, but we expect the resulting improvements to patient access and interoperable exchange of health information to significantly benefit patients and health care providers and improve the quality of health care provided. Better capture and documentation of diagnostic imaging results within the electronic health record can promote greater access to this information at the point of care and enable improvements to interoperable exchange of these results between health care providers, which can reduce redundant testing and support diagnostics. Furthermore, making diagnostic imaging results electronically available to patients through their online medical records may further enable patient-mediated exchange with other health care providers. Patients would be able to access the imaging results online, download the images to their personal device, and securely transmit the results to their provider from their online medical record. Access and exchange of diagnostic imaging results is a known challenge, and these proposed modifications to the certification criteria are one step toward resolving barriers to exchange and access.</P>
                    <HD SOURCE="HD3">7. Revised Clinical Information Reconciliation and Incorporation Certification Criterion</HD>
                    <P>We propose a primary proposal and an alternative proposal for revising the “Clinical information reconciliation and incorporation” certification criterion in § 170.315(b)(2) to expand the number and types of data elements that Health IT Modules certified to this criterion would be required to reconcile and incorporate. Our primary proposal would require Health IT Modules certified to this criterion to be capable of reconciling and incorporating all 21 data classes in USCDI Version 4 (v4), which would include expanding “clinical information reconciliation and incorporation” certification criterion to 18 new data classes beyond the existing three data classes presently required as part of the current certification criterion's functionality. Our alternative proposal would require Health IT Modules certified to this criterion to be capable of reconciling and incorporating six additional USCDI v4 data classes beyond the existing three data classes presently required as part of the current certification criterion's functionality. We also propose a new functional requirement that would allow end users to configure how their product handles information received from external sources.</P>
                    <HD SOURCE="HD3">Costs</HD>
                    <P>The primary proposal would require Health IT Modules certified to this § 170.315(b)(2) to be capable of reconciling and incorporating all USCDI v4 data classes. We have estimated the proposed cost to health IT developers to reconcile and incorporate all USCDI v4 data classes. These estimates are detailed in Tables 10 to 13 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. Tables 10 and 12 shows the estimated labor costs per product for a health IT developer to develop support for the additional data classes in USCDI v4. 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 Tables 11 and 13.</P>
                    <P>2. We estimate that 250 products certified by 209 developers will be affected by our proposal. These estimates are a subset of the total estimated health IT developers and certified products we estimated above and apply to both the primary and alternative proposal.</P>
                    <P>The estimate of 250 products certified by 209 developers is derived as follows. We estimate that, in total, 387 health IT developers will certify 521 health IT products impacted by this rulemaking. However, not all these developers and products certify to § 170.315(b)(2) certification criterion and need to meet the proposed requirements. As of the end of 2022, 54% of developers certified a product to the § 170.315(b)(2) certification criterion and 48% of all products were certified to the § 170.315(b)(2) certification criterion. We applied this modifier to our total developer and product estimate as an overall estimate of the number of developers and products impacted by the proposed modifications to the certification 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 $127.82.</P>
                    <BILCOD>BILLING CODE 4150-45-P</BILCOD>
                    <GPH SPAN="3" DEEP="640">
                        <PRTPAGE P="63676"/>
                        <GID>EP05AU24.013</GID>
                    </GPH>
                    <GPH SPAN="3" DEEP="256">
                        <PRTPAGE P="63677"/>
                        <GID>EP05AU24.014</GID>
                    </GPH>
                    <P>The cost to health IT developers to meet the proposed requirements in § 170.315(b)(2) would range from $536,844 to $1,993,992 per product, on average. This would be a one-time cost to developers per product that is certified to the specified certification criterion and would not be perpetual. Assuming 250 products overall and a labor rate of $127.82 per hour, we estimate that the total cost for all products would, on average, range from $134 million to $498 million.</P>
                    <GPH SPAN="3" DEEP="640">
                        <PRTPAGE P="63678"/>
                        <GID>EP05AU24.015</GID>
                    </GPH>
                    <GPH SPAN="3" DEEP="261">
                        <PRTPAGE P="63679"/>
                        <GID>EP05AU24.016</GID>
                    </GPH>
                    <GPH SPAN="3" DEEP="99">
                        <GID>EP05AU24.017</GID>
                    </GPH>
                    <BILCOD>BILLING CODE 4150-45-C</BILCOD>
                    <P>The cost to health IT developers to meet the proposed alternative requirements in § 170.315(b)(2) would range from $178,948 to $664,664 per product, on average. This would be a one-time cost to developers per product that is certified to the specified certification criterion and would not be perpetual. Assuming 250 products overall and a labor rate of $127.82 per hour, we estimate that the total cost for all products would, on average, range from $45 million to $168 million.</P>
                    <HD SOURCE="HD3">Benefits</HD>
                    <P>
                        We believe this proposal would benefit health care providers, patients, and the health IT industry. Expanding our clinical information reconciliation and incorporation (certification criterion to include all USCDI data classes would expand functionality by encouraging developers to include features that would allow end users (
                        <E T="03">i.e.,</E>
                         providers) to configure how their product handles information received from external sources, thus benefiting providers by reducing the burden of incorporation and reconciliation in clinical workflows, which may otherwise have occurred via manually documenting information from external source in the Health IT Module. By reducing the time clinicians spent on incorporation and reconciliation in clinical workflows, more quality time could be used on making clinical decisions.
                        <SU>286</SU>
                        <FTREF/>
                         Additionally, we believe that these requirements supporting automatic reconciliation would help equip providers with relevant and critical clinical information that can improve overall patient care and safety. For instance, automatic reconciliation of radiology reports and discharge summaries has demonstrated improvements in patient safety by identifying potentially undiagnosed limb abnormalities, this example is applicable to USCDI v4's data elements, including discharge summary note and diagnostic imaging report.
                        <SU>287</SU>
                        <FTREF/>
                         In a Hosseini, et al. study asking health care providers to reconcile healthcare information across multiple electronic documents from a health information exchange network, automatic reconciliation was more accurate and significantly reduced the reconciliation time for medications, referrals and problems (38.1%, 58.8%, and 65.1%, respectively).
                        <SU>288</SU>
                        <FTREF/>
                         Another Hosseini study showed automating reconciliation of Continuity of Care Documents took 3.3 minutes with high accuracy compared to manual reconciliation that required approximately 150 hours with the same data, resulting in additional staff time and cost savings.
                        <E T="51">289 290</E>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>286</SU>
                             
                            <E T="03">https://go.chilmarkresearch.com/from-connectivity-to-real-provider-usability.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>287</SU>
                             
                            <E T="03">https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4765582/.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>288</SU>
                             
                            <E T="03">https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6804409/pdf/ocy158.pdf.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>289</SU>
                             
                            <E T="03">https://www.sciencedirect.com/science/article/pii/S1532046417301983.</E>
                        </P>
                        <P>
                            <SU>290</SU>
                             
                            <E T="03">https://www.healthcareitnews.com/news/rural-hospital-improves-meds-reconciliation-ai-automation-ehr.</E>
                        </P>
                    </FTNT>
                    <P>
                        These two studies offer supporting evidence on the potential benefits of our proposed updates to the certification criterion in § 170.315(b)(2) by 
                        <PRTPAGE P="63680"/>
                        expanding our existing CIRI certification requirements to additional data elements and promoting new capabilities that would benefit providers by reducing the burden of reconciliation and incorporation in clinical workflows. There are potential time and cost savings by using consolidated documents to reconcile patient information and automatic reconciliation to de-duplicate information received from external sources. Our proposal to expand CIRI certification requirements to include additional data elements and promoting new capabilities will help scale these benefits to create greater impact.
                    </P>
                    <P>
                        As information exchange, especially across large networks, grows, reconciling these documents—often received or pushed via automatic machine queries—can be a large burden on clinicians who must review and reconcile when new documents are received. For example, Carequality, a large national network that connects over 600,000 clinicians and 4,200 hospitals, alone claims to facilitate the exchange of 400,000,000 documents monthly.
                        <SU>291</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>291</SU>
                             
                            <E T="03">https://carequality.org/.</E>
                             Accessed: January 2, 2024.
                        </P>
                    </FTNT>
                    <P>
                        Measuring the volume of record exchange and the rate of reconciliation are important to fully quantify the impact and potential benefits of manual versus automatic reconciliation of these documents. For instance, in the Hosseini, et al. study referenced above, the authors studied the effect of manual review and reconciliation of over 500 documents and entries in three document data classes—Problems, Allergies, and Medications—and found an over 99% reduction in time spent comparing and de-duplicating the information across all documents manually versus through a software program.
                        <SU>292</SU>
                        <FTREF/>
                         However, how the reconciliation time savings for these data classes compare to other data classes proposed to be included in the certification criterion are unknown. In addition, the representativeness of the CCDs used in the study to all CCDs exchanged nationally is unknown. Whether the CCDs selected for the study present more or less burden to reconcile than the average document is unknown.
                    </P>
                    <FTNT>
                        <P>
                            <SU>292</SU>
                             
                            <E T="03">https://www.sciencedirect.com/science/article/pii/S1532046417301983.</E>
                        </P>
                    </FTNT>
                    <P>We seek public comments on our proposed updates to the certification criterion in § 170.315(b)(2). Specifically, we seek public comments on the (1) volume of documents received electronically from external sources where reconciliation is necessary, and automation would reduce clinician burden and (2) the similarity of reconciliation burden between the problems, allergies, and medications data classes included currently in the certification criterion and data classes proposed to be included in the certification criterion.</P>
                    <P>
                        Although the exact benefits of these modifications are not quantifiable at this time, research has shown promising potential in cost savings, and we expect the resulting improvements to interoperable exchange of health information to significantly benefit providers and patients while improving the quality of health care provided.
                        <E T="51">293 294</E>
                        <FTREF/>
                         Health care providers, patients, and the health IT industry will benefit from the proposed updates to the certified criterion through support of clinical information reconciliation and incorporation of an expanded list of data elements and functionalities that would increase standardization and interoperability better support of. We look forward to public comments that will inform the quantifiable benefits of this proposal.
                    </P>
                    <FTNT>
                        <P>
                            <SU>293</SU>
                             
                            <E T="03">https://academic.oup.com/jamia/article/19/3/328/2909132.</E>
                        </P>
                        <P>
                            <SU>294</SU>
                             
                            <E T="03">https://www.healthcareitnews.com/news/rural-hospital-improves-meds-reconciliation-ai-automation-ehr.</E>
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">8. Revised Electronic Prescribing Certification Criterion</HD>
                    <P>We propose to update the “electronic prescribing” certification criterion in § 170.315(b)(3) to incorporate the NCPDP SCRIPT standard version 2023011. In addition to incorporating NCPDP SCRIPT standard version 2023011, we also propose updates to the current transactions included in § 170.315(b)(3), propose removing some transactions, and propose several new transactions considering new and updated developments in the NCPDP SCRIPT standard version 2023011 and other considerations, as well as other necessary updates to vocabulary standards and coding.</P>
                    <HD SOURCE="HD3">Costs</HD>
                    <P>The proposed updates to the “electronic prescribing” certification criterion include six tasks: (1) incorporate NCPDP SCRIPT Standard Version 2023011 for all required transactions; (2) (i) require 8 Electronic Prior Authorization transactions, currently optional under the certification criterion, and (ii) adopt and require the PANotification transaction; (3) require Signatura (Sig) transaction and require that health IT developers must be able to send an unstructured Sig and a structured and codified Sig from a prescriber to a pharmacy containing a consistent expression for communication between the prescriber and the pharmacist, according to the standard; (4) adopt FDA National Drug Code (NDC) terminology for coded drugs; (5) adopt RxNorm July 5, 2022, Full Monthly Release, which updates the current reference to RxNorm, September 8, 2015; and (6) we propose in § 170.315(b)(3)(ii)(B) that a Health IT Module certified to the “electronic prescribing” certification criterion must enable a user to exchange race and ethnicity information for a patient when performing the following prescription-related electronic transactions: RxFill; RxChangeRequest, RxChangeResponse; CancelRx; and RxRenewalRequest, RxRenewalResponse in accordance with NCPDP SCRIPT Standard Version 2023011. These tasks have their own levels of effort, and these estimates are detailed in Tables 15 and 16 below and are based on the following assumptions:</P>
                    <P>1. Health IT developers will use the same labor costs and data models. Table 15 shows the estimated labor costs per product to modify the “electronic prescribing” certification 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 16.</P>
                    <P>2. We estimate that 208 products certified by 163 developers will be affected by our proposal. These estimates are a subset of the total estimated health IT developers and certified products we estimated above.</P>
                    <P>The estimate of 208 products certified by 163 developers is derived as follows. We estimate that, in total, 387 health IT developers will certify 521 health IT products impacted by this rulemaking. However, not all these developers and products certify to the “electronic prescribing” certification criterion and need to meet the proposed requirements. As of the end of 2022, 42% of developers and 40% of products certified to the “electronic prescribing” certification criterion. We applied this modifier to our total developer and product estimate as an overall estimate of the number of developers and products impacted by the proposed modifications to the certification 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 $127.82.</P>
                    <BILCOD>BILLING CODE 4150-45-P</BILCOD>
                    <GPH SPAN="3" DEEP="640">
                        <PRTPAGE P="63681"/>
                        <GID>EP05AU24.018</GID>
                    </GPH>
                    <GPH SPAN="3" DEEP="637">
                        <PRTPAGE P="63682"/>
                        <GID>EP05AU24.019</GID>
                    </GPH>
                    <GPH SPAN="3" DEEP="390">
                        <PRTPAGE P="63683"/>
                        <GID>EP05AU24.020</GID>
                    </GPH>
                    <GPH SPAN="3" DEEP="250">
                        <GID>EP05AU24.021</GID>
                    </GPH>
                    <PRTPAGE P="63684"/>
                    <BILCOD>BILLING CODE 4150-45-C</BILCOD>
                    <P>The cost to a health IT developer to make the proposed modifications to the “electronic prescribing” certification criterion for its Health IT Module would range from $77,970 to $618,649 per product, on average. Therefore, assuming 208 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 $16.2 million to $128.7 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>
                        The proposed updates to the “electronic prescribing” certification criterion in § 170.315(b)(3) align the certification criterion with an updated version of the NCPDP SCRIPT Standard. For 
                        <E T="03">Task 1,</E>
                         this alignment is in step with a reciprocal Medicare Part D requirement for Part D sponsors, prescribers, and dispensers, when electronically transmitting prescriptions and prescription-related information for covered Part D drugs for Part D eligible individuals, to use a standard in § 170.205(b), which includes the NCPDP SCRIPT standard version 2023011, for all required and optional electronic prescribing transactions. NCPDP SCRIPT standard version 2023011 includes important updates to terminology standards, transactions, and other data elements. Moreover, the adoption through rulemaking of a new NCPDP SCRIPT standard version and new proposed updates to the certification criterion for 
                        <E T="03">Electronic Prescribing</E>
                         align with public feedback and consensus on how to make these transactions and the “electronic prescribing” certification criterion more interoperable.
                    </P>
                    <P>
                        For 
                        <E T="03">Task 2,</E>
                         comments from ONC's “Request for Information: Electronic Prior Authorization Standards, Implementation Specifications, and Certification Criteria,” published on January 24, 2022, stated that making the Prior Authorization transactions required would help to advance interoperability and reduce administrative burden around prior authorization processes for medications. Requiring these transactions would help ensure pharmacy data systems are able to communicate similarly across all Health IT modules certified to this certification criterion and would not have to build different processes for prior authorization across different certified health IT.
                    </P>
                    <P>
                        For 
                        <E T="03">Task 3,</E>
                         communicating how a prescriber intends for a patient to take a medication is critical for safe and effective care. These instructions are essential for accurate prescription labeling, appropriate patient counseling and education from a pharmacist, and optimal medication use. The industry has been slow to adopt structured and codified Sig functionality, most frequently using the unstandardized format of unstructured free text Sigs. The wide variation in unstructured Sig limits the clarity, utility, and reusability of the data—curbing its potential impact on patient safety and clinical outcomes. Sig is also an important factor in a provider's capacity to follow the CDC Guideline for Prescribing Opioids for Chronic Pain, especially in cases where the provider lacks information about days' supply, but still seeks to calculate quality improvement opioid measures as part of a larger strategy to support careful and selective use of long-term opioid therapy in the context of managing chronic pain.
                        <SU>295</SU>
                        <FTREF/>
                         The Sig requirement provides greater clarity, utility, and reusability of the data, moving from an unstructured free text Sig to a structured and codified functionality.
                    </P>
                    <FTNT>
                        <P>
                            <SU>295</SU>
                             
                            <E T="03">https://www.cdc.gov/drugoverdose/pdf/Guidelines_At-A-Glance-508.pdf.</E>
                        </P>
                    </FTNT>
                    <P>
                        For 
                        <E T="03">Task 4,</E>
                         the NDC is critical for specific product identification in research, dispensing and administrative workflows. The NDC is the key, unique, product identifier and is the standard of practice used throughout the pharmacy industry to identify the specific product. The pharmacy industry heavily relies on the NDC in all aspects of its business, including, but not limited to, drug ordering, medication dispensing, reporting, billing, rebates, adverse event reporting and patient safety. In NCPDP SCRIPT standard version 2023011, NDC is now required for coded drugs in the standard. NDC is also adopted as a medical data code set for reporting drugs and biologics on retail pharmacy claims under the HIPAA Transaction and Code Set rule.
                        <SU>296</SU>
                        <FTREF/>
                         Use of NDC will ensure greater interoperability with pharmacy data systems and facilitate correct identification of prescribed products.
                    </P>
                    <FTNT>
                        <P>
                            <SU>296</SU>
                             45 CFR 162.1002(a)(3).
                        </P>
                    </FTNT>
                    <P>
                        For 
                        <E T="03">Task 5,</E>
                         updating Health IT Modules to the latest RxNorm standard version is very important for interoperability. Modules certified to this certification criterion, currently, align with a prior RxNorm standard version, so this new requirement transitions technology to the newest standard version, which will ensure Health IT modules certified to this certification criterion all use the same code sets and can communicate with pharmacy data systems more effectively.
                    </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 prescribers, pharmacists, payers, and patients and improve the quality of health care provided. These proposed requirements align with a reciprocal Medicare Part D requirement in “Medicare Program; Contract Year 2025 Policy and Technical Changes to the Medicare Advantage Program, Medicare Prescription Drug Benefit Program, Medicare Parts A, B, C, and D Overpayment Provisions of the Affordable Care Act and Programs of All-Inclusive Care for the Elderly; Health Information Technology Standards and Implementation Specifications” proposed rule for Part D sponsors, prescribers, and dispensers, when electronically transmitting prescriptions and prescription-related information for covered Part D drugs for Part D eligible individuals, to use a standard in § 170.205(b), which includes the NCPDP SCRIPT standard version. Prescribers, pharmacists, and payers will benefit from the updates to the standards and to the certified criterion through increased standardization and interoperability of electronic prescribing.</P>
                    <HD SOURCE="HD3">9. New Real-Time Prescription Benefit Certification Criterion</HD>
                    <P>We propose to establish a real-time prescription benefit (RTPB) certification criterion in § 170.315(b)(4) based on National Council for Prescription Drug Programs (NCPDP) RTPB standard version 13 and include this certification criterion in the Base EHR definition in § 170.102. We believe including the RTPB certification criterion will markedly increase the use of RTPB tools and promote widespread adoption, which will help to lower drug costs for Medicare beneficiaries. Use of RTBTs enables Medicare providers and enrollees to make cost-informed decisions about prescriptions, and a standardized approach will ensure that critical drug and drug price data is available to providers when they need it.</P>
                    <P>The proposed certification criterion includes the following standards and functional requirements:</P>
                    <P>
                        • Incorporate the NCPDP Real-Time Prescription Benefit (RTPB) standard version 13 and vocabulary standards, RxNorm (§ 170.207(d)(1)) and National Drug Codes (§ 170.207(d)(2)), to enable a user to send and receive patient-specific benefit, estimated cost information, and 
                        <PRTPAGE P="63685"/>
                        therapeutic alternatives within workflow at the point of care, specifically standard transactions:
                    </P>
                    <P>• Mandatory and situational transaction segments and associated data elements for RTPBRequests and RTPBResponse transactions;</P>
                    <P>• RTPBError transaction;</P>
                    <P>• Exclusive use of XML format for all transactions; and</P>
                    <P>• Require use for medications and vaccines covered by a pharmacy benefit.</P>
                    <P>NCPDP RTPB standard version 13 permits the use of the EDI or XML format for payloads. ONC proposes that a Health IT module certified to the certification criterion must enable a user to perform the specified NCPDP RTPB standard version 13 transactions using the XML format. ONC, similarly, requires that a Health IT Module certified to the “electronic prescribing” certification criterion, which uses the NCPDP SCRIPT standard, use the XML format for payloads. Public comments on ONC's RTPB RFI in the HTI-1 NPRM broadly supported use of XML. We do not estimate additional costs to developers to exclusively use XML to implement this certification criterion, as it is broadly supported and required as part of another functionally similar “electronic prescribing” certification criterion. The proposed certification criterion also would only require use of NCPDP RTPB standard version 13 to send and receive patient-specific benefit, estimated cost information, and therapeutic alternatives for medication and vaccine products, and would not include required use for medical device products. We do not estimate additional costs to developers to implement the standard and certification criterion in this manner.</P>
                    <HD SOURCE="HD1">Background</HD>
                    <P>
                        ONC analysis of the 2022 American Hospital Association Health Information Technology Supplement indicates that half (50.2%) of hospitals have implemented EHR functionality that integrates health insurer real-time prescription benefit information for all or nearly all payers; another 15.9% have implemented such a functionality for a limited set of payers.
                        <SU>297</SU>
                        <FTREF/>
                         However, hospital implementation of RTPB tools does not necessarily translate to widespread prescriber adoption in or out of the hospital. The American Medical Association (AMA) reports that its 2020 member survey of physicians explained RTPB tools to responding physicians and found that only 35.7% had heard of the tool; among those who had heard of it, only 55% actually had access.
                        <SU>298</SU>
                        <FTREF/>
                         The AMA survey did find high uptake of RTPB tools among physicians with access, with that group over four times more likely to report use of the RTPB tool than not.
                        <SU>299</SU>
                        <FTREF/>
                         Limited adoption may be due to the proprietary and therefore fragmented nature of RTPB tools. The American Health Information Management Association argues that the largest barrier to implementing RTPB is “not a lack of will, but rather a lack of ability due to technical barriers.” 
                        <SU>300</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>297</SU>
                             
                            <E T="03">https://www.healthit.gov/data/quickstats/hospital-adoption-real-time-benefit-tools.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>298</SU>
                             
                            <E T="03">https://councilreports.ama-assn.org/councilreports/downloadreport?uri=/councilreports/n21_cms_report_2.pdf.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>299</SU>
                             Ibid.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>300</SU>
                             
                            <E T="03">https://www.ahima.org/media/rrije1di/ahima-onc-hti-1-comments-final.pdf.</E>
                        </P>
                    </FTNT>
                    <P>
                        Our market research found multiple tools available in the marketplace from health IT software vendors; health plans; and pharmacy benefit managers (PBMs).
                        <E T="51">301 302 303 304 305</E>
                        <FTREF/>
                         There is choice in the market for these tools; however, without broadly adopted standards and standardized implementation, use of these tools can become fragmented and such fragmentation can impede interoperability. To realize the overall benefits of RTPB tools—increased patient choice; reduced medication costs and out-of-pocket patient expenses; reduced provider time and effort to identify and prescribe a covered medication; and ease of dispensing by PBMs—technology must be implemented that minimizes disruption to EHR usability, minimizes costs to physicians and hospitals, and ensures accuracy and consistency of pricing and coverage information.
                        <SU>306</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>301</SU>
                             
                            <E T="03">https://surescripts.com/who-we-serve/ehr-vendors.</E>
                        </P>
                        <P>
                            <SU>302</SU>
                             
                            <E T="03">https://arrivehealth.com/wp-content/uploads/2022/11/Arrive-Health-Physician-Insights-Whats-Needed-to-Improve-Prescribing-Workflows.pdf.</E>
                        </P>
                        <P>
                            <SU>303</SU>
                             
                            <E T="03">https://www.optum.com/content/dam/optum4/resources/pdf/wf2167397_pcs_improving_prescribing_process.pdf.</E>
                        </P>
                        <P>
                            <SU>304</SU>
                             
                            <E T="03">https://www.humana.com/provider/pharmacy-resources/tools/real-time-benefit-tool#:~:text=Real%2DTime%20Benefit%20Check%20(RTBC,your%20electronic%20medical%20record%20representative.</E>
                        </P>
                        <P>
                            <SU>305</SU>
                             
                            <E T="03">https://www.express-scripts.com/corporate/articles/scriptvision-gives-physicians-real-time-access-patient-specific-information</E>
                            .
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>306</SU>
                             Ibid.
                        </P>
                    </FTNT>
                    <P>Development and incorporation of these tools into certified health IT is, however, not without cost. As described above, about 2 in 3 hospitals use any type of RTPB tool and, according to one study, less than 1 in 4 physicians uses the tool (far more lack knowledge of or access to one). This may be due to fragmented availability and implementation of tools across EHR vendors. We have no universal assessment of tool adoption and implementation across all EHRs. Information gathered through conversations with several EHR market leaders reveal variation in adoption and implementation. Some have deployed their own tools; some depend on third-party developers to provide these services; and others do not currently deploy a tool to their customers. There's also mixed adoption and perspectives on standard approaches to develop and deploy these tools, with some developers being supportive of tools using the NCPDP RTPB standard and others agnostic.</P>
                    <P>Furthermore, as finalized in the “Medicare and Medicaid Programs; Contract Year 2022 Policy and Technical Changes to the Medicare Advantage Program, Medicare Prescription Drug Benefit Program, Medicaid Program, Medicare Cost Plan Program, and Programs of All-Inclusive Care for the Elderly' final rule regulatory impact analysis (86 FR 5864), CMS policy to require entities to implement a RTBT would have costs on providers and payers. These costs are separate from the costs estimated here to adopt the proposed certification criterion but reflect estimated costs for end-users of the technology to implement in a real world setting.</P>
                    <HD SOURCE="HD3">Costs</HD>
                    <P>
                        Dependency on specific health IT vendor or health plan efforts alone to provide these tools may not lead to broader availability and adoption. The proposed certification criterion incorporates the NCPDP RTPB standard version 13, which was piloted successfully in at least one study, and adopts functional requirements that align with implementation of the standard to facilitate interoperability between prescribing systems, plans, and PBMs.
                        <SU>307</SU>
                        <FTREF/>
                         The standard was published in October 2021. Since that time, there have been new enhancements added to the standard at the request of end users, resulting in version 13.
                        <SU>308</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>307</SU>
                             
                            <E T="03">https://ncpdpfoundation.org/pdf/NCPDPFoundationRTPBGrant_FinalReport.pdf</E>
                            .
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>308</SU>
                             
                            <E T="03">https://ncpdp.org/NCPDP/media/pdf/RTPB-Standard-Implementation-Recommendations-v1-1.pdf?ext=.pdf</E>
                            .
                        </P>
                    </FTNT>
                    <P>
                        We estimate costs to certified health IT developers to incorporate the NCPDP Real-Time Prescription Benefit (RTPB) standard version 13 and vocabulary standards, RxNorm (§ 170.207(d)(1)) and National Drug Codes (§ 170.207(d)(2)) to send and receive mandatory and situational transaction segments and associated data elements for RTPBRequests and RTPBResponse 
                        <PRTPAGE P="63686"/>
                        transactions and the RTPBError transaction.
                    </P>
                    <P>These tasks have their own levels of effort, and these estimates are detailed in Tables 17 and 18 below and are based on the following assumptions:</P>
                    <P>1. Health IT developers will use the same labor costs and data models. Table 17 shows the estimated labor costs per product to develop the certification 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 18.</P>
                    <P>2. We estimate that 208 products certified by 163 developers will be affected by our proposal. These estimates are a subset of the total number of estimated health IT developers and certified products we estimated above.</P>
                    <P>The estimate of 208 products certified by 163 developers is derived as follows. We estimate that, in total, 387 health IT developers will certify 521 health IT products impacted by this rulemaking. We propose to require Health IT Modules certified to the electronic prescribing certification criterion to certify to the proposed RTPB certification criterion. We, therefore, use the estimated number of developers and products that certify to the “electronic prescribing” certification criterion as a proxy for the expected number of developers and products that will certify the proposed RTPB certification criterion. As of the end of 2022, 42% of developers and 40% of products certified to the “electronic prescribing” certification criterion. We applied this modifier to our total developer and product estimate as an overall estimate of the number of developers and products impacted by the proposed certification 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 $127.82.</P>
                    <BILCOD>BILLING CODE 4150-45-P</BILCOD>
                    <GPH SPAN="3" DEEP="640">
                        <PRTPAGE P="63687"/>
                        <GID>EP05AU24.022</GID>
                    </GPH>
                    <GPH SPAN="3" DEEP="111">
                        <PRTPAGE P="63688"/>
                        <GID>EP05AU24.023</GID>
                    </GPH>
                    <BILCOD>BILLING CODE 4150-45-C</BILCOD>
                    <P>The cost to a health IT developer to develop the Real-Time Prescription Benefit (RTPB) certification criterion for their Health IT Modules would range from $74,136 to $148,271 per product, on average. Therefore, assuming 208 products overall and a labor rate of $127.82 per hour, we estimate that the total cost to all health IT developers would, on average, range from $15.4 million to $30.8 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>
                        CMS finalized in the `Medicare and Medicaid Programs; Contract Year 2022 Policy and Technical Changes to the Medicare Advantage Program, Medicare Prescription Drug Benefit Program, Medicaid Program, Medicare Cost Plan Program, and Programs of All-Inclusive Care for the Elderly' final rule (86 FR 5864) that Part D sponsors implement a real-time benefit tool by January 1, 2023.
                        <SU>309</SU>
                        <FTREF/>
                         According to one source, as of the end of 2022, 98% of U.S. prescribers were served by EHRs with access to an available RTBT tool, and over half of prescribers used real-time prescription benefit to access medication pricing. So, although nearly all prescribers have an EHR with an available tool, more than half use it.
                        <SU>310</SU>
                        <FTREF/>
                         The proposed certification criterion would incorporate published, adopted standards and functional requirements that promote interoperability and patient choice. Furthermore, the revised certification criterion would provide a standardized implementation for health IT developers to support end-users to meet Medicare Part D requirements finalized in 86 FR 5864 for prescribers to implement a RTPB tool. This certification criterion would enable interoperability between certified health IT, plans, and PBMs, helping deliver on the promising benefits of the real-time ability of providers and their patients to make informed choices about medications and costs.
                    </P>
                    <FTNT>
                        <P>
                            <SU>309</SU>
                             
                            <E T="03">https://www.federalregister.gov/documents/2021/01/19/2021-00538/medicare-and-medicaid-programs-contract-year-2022-policy-and-technical-changes-to-the-medicare</E>
                            .
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>310</SU>
                             
                            <E T="03">https://surescripts.widen.net/s/mvtqvvf5sd/2022-national-progress-report#page=1</E>
                            .
                        </P>
                    </FTNT>
                    <P>There are benefits for providers, patients, PBMs, and technology developers, and benefits from implementation of a RTPB tool are likely to manifest via multiple pathways. Standardization can lead to implementation and uptake of RTPB tools, and tool implementation can reduce time and effort and improve the accuracy of information, lead to reduced prescription costs for patients and payers, improve medication adherence, and generate other downstream benefits.</P>
                    <P>
                        The real-time prescription benefit (RTPB) standard was developed by a multi-stakeholder, consensus-building process led by the National Council for Prescription Drug Programs (NCPDP). A standard format for data exchange is important for all exchange partners to share real-time information about a patient's drug benefit coverage and out-of-pocket cost prior to prescribing and dispensing.
                        <SU>311</SU>
                        <FTREF/>
                         By standardizing the data elements and process of exchanging data between an EHR, an intermediary, and a PBM, “there is significant potential to directly impact the price transparency landscape and reduce out-of-pocket costs for patients.” 
                        <SU>312</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>311</SU>
                             
                            <E T="03">https://ncpdpfoundation.org/pdf/NCPDPFoundationRTPBGrant_FinalReport.pdf</E>
                            .
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>312</SU>
                             Ibid.
                        </P>
                    </FTNT>
                    <P>
                        Studies have shown that patients who pay less for their medications overall have higher rates of medication adherence. A review of interventions to improve medication adherence found that reducing out-of-pocket costs to patients can be an effective mechanism.
                        <SU>313</SU>
                        <FTREF/>
                         Consistent with this, ONC-affiliated researchers conducted a survey of respondents 65 and older, finding that 20.2% reported cost-related medication non-adherence—most often delaying prescription fills, not filling prescriptions, or skipping doses.
                        <SU>314</SU>
                        <FTREF/>
                         The majority of respondents (79.3%) expressed a desire to speak to their physician about the cost of all or some of their medications, with respondents who reported cost-related non-adherence more likely.
                        <SU>315</SU>
                        <FTREF/>
                         Reducing prescription copays and formulary decision support have previously been shown to improve medication adherence,
                        <E T="51">316 317</E>
                        <FTREF/>
                         suggesting that RTPB tools may also be a useful mechanism. One retrospective study appears to support this, finding that prescriptions placed using RTPB were associated with a higher fill rate (79.8% vs. 71.7%) and lower cancellation rate (9.3% vs. 14.9%).
                        <SU>318</SU>
                        <FTREF/>
                         The same researchers found that prescribers using RTPB adjusted days of supply for 44% of medication orders and quantity for 69% of orders, which can support adherence.
                        <SU>319</SU>
                        <FTREF/>
                         A cluster-randomized trial of RTPB implementation resulted in 11.2% out-of-pocket savings for patients after controlling for patient and prescriber characteristics; savings were even higher (38.9%) for drugs with the highest out-of-pocket costs.
                        <SU>320</SU>
                        <FTREF/>
                         This study, however, did not find a change in the proportion of orders for 90-day supply despite identifying overall cost savings.
                        <SU>321</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>313</SU>
                             
                            <E T="03">https://www.acpjournals.org/doi/10.7326/0003-4819-157-11-201212040-00538</E>
                            .
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>314</SU>
                             
                            <E T="03">https://jamanetwork.com/journals/jamanetworkopen/fullarticle/2805012</E>
                            .
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>315</SU>
                             Ibid.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>316</SU>
                             
                            <E T="03">https://jamanetwork.com/journals/jamainternalmedicine/fullarticle/409766.</E>
                        </P>
                        <P>
                            <SU>317</SU>
                             
                            <E T="03">https://jamanetwork.com/journals/jamainternalmedicine/fullarticle/773454.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>318</SU>
                             
                            <E T="03">https://www.sciencedirect.com/science/article/abs/pii/S0002934322005289?via%3Dihub</E>
                             via 
                            <E T="03">https://link.springer.com/article/10.1007/s11606-022-07945-z</E>
                            .
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>319</SU>
                             
                            <E T="03">https://www.ajmc.com/view/implementation-and-cost-validation-of-a-real-time-benefit-tool</E>
                            .
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>320</SU>
                             
                            <E T="03">https://jamanetwork.com/journals/jamainternalmedicine/fullarticle/2796059</E>
                            .
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>321</SU>
                             Ibid.
                        </P>
                    </FTNT>
                    <P>
                        An ONC-affiliated research review notes that 86% of providers believe that cost should influence treatment decisions, but barriers to cost conversations include physicians' knowledge of patients' cost burdens and lack of information about insurance coverage and prices.
                        <SU>322</SU>
                        <FTREF/>
                         Work by ONC-
                        <PRTPAGE P="63689"/>
                        affiliated researchers has highlighted the desire of patients to have conversations about costs with their prescribers.
                        <E T="51">323 324</E>
                        <FTREF/>
                         89.5% of respondents indicated a desire for physicians to use real-time benefit tools and 89.8% indicated a desire to discuss the estimated prices, with greater interest among those with any cost-related nonadherence.
                        <SU>325</SU>
                        <FTREF/>
                         While other tools such as formulary guides exist that can help facilitate cost conversations and lead to savings, that information is not real-time and may not be up to date,
                        <SU>326</SU>
                        <FTREF/>
                         and patients may lose confidence in estimates or their providers if the provided information proves to be wrong.
                        <SU>327</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>322</SU>
                             
                            <E T="03">
                                https://journals.sagepub.com/doi/10.1177/10775587221108042?url_ver=Z39.88-
                                <PRTPAGE/>
                                2003&amp;rfr_id=ori:rid:crossref.org&amp;rfr_dat=cr_pub%20%200pubmed
                            </E>
                            .
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>323</SU>
                             
                            <E T="03">https://jamanetwork.com/journals/jamanetworkopen/fullarticle/2805012.</E>
                        </P>
                        <P>
                            <SU>324</SU>
                             
                            <E T="03">https://agsjournals.onlinelibrary.wiley.com/doi/10.1111/jgs.18226.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>325</SU>
                             Ibid.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>326</SU>
                             
                            <E T="03">https://councilreports.ama-assn.org/councilreports/downloadreport?uri=/councilreports/n21_cms_report_2.pdf</E>
                            .
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>327</SU>
                             
                            <E T="03">https://jamanetwork.com/journals/jamanetworkopen/fullarticle/2805012</E>
                            .
                        </P>
                    </FTNT>
                    <P>
                        Provider use of tools may provide more informed choices to their patients, and also increase prescribers' efficiencies prescribing and approving products. In a survey of providers commissioned by an RTPB tool, a majority of respondents stated they need to change or manage a prescription order more than 25% of the time after it has been sent to the pharmacy.
                        <SU>328</SU>
                        <FTREF/>
                         When one research hospital's health system implemented their RTPB tool, researchers were able to guide prescribers to choose alternatives without prior authorization requirements, convert from drugs covered with restrictions, and/or to convert from drugs not covered to one covered with restrictions.
                        <SU>329</SU>
                        <FTREF/>
                         An additional study estimates that avoiding prior authorization is another way in which providers using its RTPB tool save time, estimating approximately 50 minutes of time saved for alternative prescriptions that avoid necessitating a prior authorization.
                        <SU>330</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>328</SU>
                             
                            <E T="03">https://arrivehealth.com/wp-content/uploads/2022/11/Arrive-Health-Physician-Insights-Whats-Needed-to-Improve-Prescribing-Workflows.pdf</E>
                            .
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>329</SU>
                             
                            <E T="03">https://ncpdpfoundation.org/pdf/NCPDPFoundationRTPBGrant_FinalReport.pdf</E>
                            .
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>330</SU>
                             
                            <E T="03">https://www.optum.com/content/dam/optum4/resources/pdf/wf2167397_pcs_improving_prescribing_process.pdf</E>
                            .
                        </P>
                    </FTNT>
                    <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 prescribers and patients and improve the quality of health care provided. Data show that RTPB tools are available to nearly all US prescribers through prescribers' EHRs, though only half use the tool itself.
                        <SU>331</SU>
                        <FTREF/>
                         The proposed RTPB certification criterion would standardize tools across all EHRs certified to the criterion and establish a baseline of functionality. This may increase use, but the data show the certification criterion may have a negligible effect on the availability of the tools currently. We request comment on quantifiable benefits for this certification criterion.
                    </P>
                    <FTNT>
                        <P>
                            <SU>331</SU>
                             
                            <E T="03">https://surescripts.widen.net/s/mvtqvvf5sd/2022-national-progress-report#page=1</E>
                            .
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">10. Electronic Health Information (EHI) Export—Single Patient EHI Export Exemption</HD>
                    <P>We propose an exemption policy for certain developers of Health IT Modules certified to the EHI export certification criterion to not support functionality for single patient data export. We believe this voluntary exemption does not create new costs for developers. We are also limited in our understanding of the number of developers to which the exemption policy could apply so cannot estimate any cost savings to developers for this policy. We request comment on any burden associated with this proposed exemption policy and information about the applicability of this proposed policy on developers of certified health IT.</P>
                    <HD SOURCE="HD3">11. Revised End-User Device Encryption Certification Criterion</HD>
                    <P>We propose to revise § 170.315(d)(7) to include a new requirement that Health IT Modules certified to this certification criterion encrypt electronic health information (EHI) stored server-side. To include this new requirement, we propose organizing certification criterion paragraphs in a way that places existing end-user device encryption requirements into § 170.315(d)(7)(i) and adds the new server encryption requirement in § 170.315(d)(7)(ii). Then we propose placing the encryption standard and default settings requirements, that we propose should apply to both the end-user device and server encryption requirements, into § 170.315(d)(7)(iii) and (iv) respectively. Finally, we propose to change § 170.315(d)(7) by renaming it to “Health IT encryption,” to better describe the end-user and proposed server-side requirements together.</P>
                    <HD SOURCE="HD3">Costs</HD>
                    <P>This section describes the estimated costs of meeting requirements in the proposed revisions to § 170.315(d)(7), which are detailed in Tables 19 and 20 below and are based on the following assumptions:</P>
                    <P>1. Health IT developers will use the same labor costs and data models. Table 19 shows the estimated labor costs per product to make the proposed updates in § 170.315(d)(7). 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 20.</P>
                    <P>2. We estimate that 448 products certified by 333 developers will be affected by our proposal. These estimates are a subset of the total estimated number of health IT developers and certified products we estimated above. The estimate of 448 products certified by 333 developers is derived as follows. We estimate that, in total, 387 health IT developers will certify 521 health IT products impacted by this rulemaking. However, not all these developers and products certify § 170.315(d)(7) and need to meet the proposed requirements. As of the end of 2022, 86% of developers and 86% of products certified § 170.315(d)(7). 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 certification criterion.</P>
                    <P>
                        3. According to the May 2022 BLS occupational employment statistics, the mean hourly wage for a “Software Developer” is $63.91.
                        <SU>332</SU>
                        <FTREF/>
                         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 $127.82.
                    </P>
                    <FTNT>
                        <P>
                            <SU>332</SU>
                             
                            <E T="03">https://www.bls.gov/oes/current/oes151252.htm</E>
                            .
                        </P>
                    </FTNT>
                    <GPH SPAN="3" DEEP="241">
                        <PRTPAGE P="63690"/>
                        <GID>EP05AU24.024</GID>
                    </GPH>
                    <GPH SPAN="3" DEEP="295">
                        <GID>EP05AU24.025</GID>
                    </GPH>
                    <P>The cost to health IT developers to meet the proposed requirements in § 170.315(d)(7) would range from $15,978 to $47,933 per product, on average. This would be a one-time cost to developers per product that is certified to the specified certification criterion and would not be perpetual. Assuming 448 products overall and a labor rate of $127.82 per hour, we estimate that the total cost for all products would, on average, range from $7.2 to $21.5 million. Assuming 333 health IT developers, this would be an average cost per developer ranging from $183,536 to $550,609.</P>
                    <HD SOURCE="HD3">Benefits</HD>
                    <P>
                        Encryption is a ubiquitous feature in modern day technology, and it is widely accepted as a best practice for data protection whenever possible. Since the 2014 Edition Final Rule, encryption technology has continued to advance significantly, and we believe expanding requirements to server-side encryption is critical and beneficial to patients, providers, and developers. Encryption of server-side data prevents unauthorized data access in many 
                        <PRTPAGE P="63691"/>
                        scenarios, including those involving a server breach, theft, or improper disposal. Mitigating these risks using encryption is a best practice for all server developers and, given the unique characteristics of EHI, is especially important for health IT server developers.
                    </P>
                    <P>
                        EHI is considered one of the most valuable types of personal information for theft because of the breadth of information included in electronic health records and the long shelf life of this information. However, despite its high value, EHI often is not being properly protected, and the problem is getting worse according to data published on the Department of Health and Human Services Office for Civil Rights (OCR) website. Between 2010 and 2022, OCR received 5,144 reports of breaches affecting 500 or more individuals, equating to 394,236,737 individuals.
                        <SU>333</SU>
                        <FTREF/>
                         The frequency of breaches affecting 500 individuals or more has increased significantly over the past few years, with almost two such large breaches reported per day in 2022, nearly double the frequency in 2018.
                        <SU>334</SU>
                        <FTREF/>
                         These statistics indicate that vulnerabilities and risks exist in EHI technology systems in the United States. While no single solution can fully protect EHI, data breach risks can be mitigated by encryption of data server-side data.
                    </P>
                    <FTNT>
                        <P>
                            <SU>333</SU>
                             
                            <E T="03">See https://ocrportal.hhs.gov/ocr/breach/breach_report.jsf.</E>
                             These numbers are based on breach reports made to OCR as of May 17, 2024.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>334</SU>
                             
                            <E T="03">See https://ocrportal.hhs.gov/ocr/breach/breach_report.jsf.</E>
                             These numbers are based on breach reports made to OCR as of May 17, 2024.
                        </P>
                    </FTNT>
                    <P>
                        Along with the rising frequency of large data breaches, there is significant and increasing cost associated with health care data breaches. In 2023, the average cost of a health care data breach was $10.93 million, which represents a 53.3% increase from 2020.
                        <SU>335</SU>
                        <FTREF/>
                         57% of organizations pass the costs of these breaches onto consumers.
                        <SU>336</SU>
                        <FTREF/>
                         While the benefits of these modifications are not quantifiable at this time, we expect the resulting improvements to help increase health care data security to significantly benefit patients, providers, and developers. Our proposed changes would also prevent many unauthorized data access and protect EHI.
                    </P>
                    <FTNT>
                        <P>
                            <SU>335</SU>
                             
                            <E T="03">https://www.hipaajournal.com/2023-cost-healthcare-data-breach/#:~:text=For%20the%2013th%20year%20in,average%20breach%20cost%20in%202022.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>336</SU>
                             
                            <E T="03">https://www.hipaajournal.com/2023-cost-healthcare-data-breach/#:~:text=For%20the%2013th%20year%20in,average%20breach%20cost%20in%202022.</E>
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">12. Revised Certification Criterion for Encrypt Authentication Credentials</HD>
                    <P>ONC proposes to revise the “encrypt authentication credentials” certification criterion in § 170.315(d)(12). Our proposed update revises the certification criterion by replacing our current “yes” or “no” attestation requirement and instead requiring Health IT Modules that store authentication credentials to protect the confidentiality and integrity of its stored authentication credentials according to October 12, 2021, version of Annex A of the Federal Information Processing Standards (FIPS) 140-2 industry standard or via hashing in accordance with the standard specified in § 170.210(c)(2). We would also change the name of this certification criterion to “Protect stored authentication credentials,” to better describe how we are revising the certification criterion.</P>
                    <HD SOURCE="HD3">Costs</HD>
                    <P>The currently adopted “encrypt authentication credentials” certification criterion instructs developers to attest “yes” or “no” that they support encrypting stored authentication credentials. An analysis of the Certified Health IT Product List (CHPL), as of the end of 2022, shows that 66% of developers attested “yes” that they support encrypting stored authentication credentials. The proposed revision requires developers that store authentication credentials to protect the confidentiality and integrity of its stored authentication credentials according to the Federal Information Processing Standards (FIPS) 140-2 instead an attestation of its use.</P>
                    <P>The estimated costs will vary depending on current developer attestations to the “encrypt authentication credentials” certification criterion. We assume an overall lower level of burden for developers who attested “yes” to support encrypting stored authentication to comply with this revised certification criterion. We separate out the costs for these developers from those that attested “no” to support encrypting stored authentication. This section describes the estimated costs of meeting requirements in the proposed revisions to § 170.315(d)(12), which are detailed in Tables 21 to 23 below and are based on the following assumptions:</P>
                    <P>1. Health IT developers will use the same labor costs and data models. Tables 21 and 22 shows the estimated labor costs per product to make the proposed updates in § 170.315(d)(12). 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 500 products certified by 372 developers will be affected by our proposal. These estimates are a subset of the total estimated health IT developers and certified products we estimated above. The estimate of 500 products certified by 372 developers is derived as follows. We estimate that, in total, 387 health IT developers will certify 521 health IT products impacted by this rulemaking. However, not all these developers and products certify § 170.315(d)(12) and need to meet the proposed requirements. As of the end of 2022, 96% of developers and 96% of products certified § 170.315(d)(12). 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 certification criterion.</P>
                    <P>
                        3. According to the May 2022 BLS occupational employment statistics, the mean hourly wage for a “Software Developer” is $63.91.
                        <SU>337</SU>
                        <FTREF/>
                         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 $127.82.
                    </P>
                    <FTNT>
                        <P>
                            <SU>337</SU>
                             
                            <E T="03">https://www.bls.gov/oes/current/oes151252.htm</E>
                            .
                        </P>
                    </FTNT>
                    <BILCOD>BILLING CODE 4150-45-P</BILCOD>
                    <GPH SPAN="3" DEEP="233">
                        <PRTPAGE P="63692"/>
                        <GID>EP05AU24.026</GID>
                    </GPH>
                    <GPH SPAN="3" DEEP="322">
                        <GID>EP05AU24.027</GID>
                    </GPH>
                    <GPH SPAN="3" DEEP="236">
                        <PRTPAGE P="63693"/>
                        <GID>EP05AU24.028</GID>
                    </GPH>
                    <BILCOD>BILLING CODE 4150-45-C</BILCOD>
                    <P>The cost to a health IT developer to meet the proposed requirements in § 170.315(d)(12) would range from $0 to $31,955 per product, on average. This would be a one-time cost to developers per product that is certified to the specified certification criterion and would not be perpetual. Therefore, assuming 500 products overall and a labor rate of $127.82 per hour, we estimate that the total cost for all products would, on average, range from $0 to $5 million.</P>
                    <HD SOURCE="HD3">Benefits</HD>
                    <P>
                        We believe this updated requirement and updated standard is necessary and important to help best protect health information. The frequency of breaches affecting 500 individuals or more has increased significantly over the past few years, with almost two large breaches reported per day in 2022, nearly double the frequency in 2018.
                        <SU>338</SU>
                        <FTREF/>
                         Along with the rising frequency of breaches affecting 500 or more individuals, there is significant and increasing cost associated with health care data breaches. In 2023, the average cost of a health care data breach was $10.93 million, which represents a 53.3% increase from 2020 and 57% of organizations pass the costs of these breaches onto consumers.
                        <SU>339</SU>
                        <FTREF/>
                         These statistics indicate that vulnerabilities and risks exist in EHI technology systems in the United States. Properly protecting stored authentication credentials in Health IT Modules is a critical defensive step to help ensure that breached authentication credentials are useless to an attacker.
                    </P>
                    <FTNT>
                        <P>
                            <SU>338</SU>
                             
                            <E T="03">See https://ocrportal.hhs.gov/ocr/breach/breach_report.jsf.https://ocrportal.hhs.gov/ocr/breach/breach_report.jsf.</E>
                             These numbers are based on breach reports made to OCR as of August 25, 2023.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>339</SU>
                             
                            <E T="03">https://www.hipaajournal.com/2023-cost-healthcare-data-breach/#:~:text=For%20the%2013th%20year%20in,average%20breach%20cost%20in%202022.</E>
                        </P>
                    </FTNT>
                    <P>
                        We believe this proposal would benefit patients, health care providers, and developers. Adopting the, October 12, 2021, version of Annex A of the FIPS Publication 140-2 in § 170.210(a)(3) will help ensure patients' data are protected and cybersecurity risks are mitigated.
                        <SU>340</SU>
                        <FTREF/>
                         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 patients, health care providers, and developers and help prevent exposure to unauthorized persons/entities. Patients, health care providers, and developers will benefit from the updates to the standard and to the certified criterion through revised criterion for encrypt authentication credentials.
                    </P>
                    <FTNT>
                        <P>
                            <SU>340</SU>
                             
                            <E T="03">https://davidhoglund.typepad.com/files/white-paper---fips-in-medical-environments-0919.pdf</E>
                            .
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">13. Health IT Modules Supporting Public Health Data Exchange</HD>
                    <HD SOURCE="HD3">a. Proposed Revised Certification Criteria for Health IT Modules Supporting Public Health Data Exchange in § 170.315(f)</HD>
                    <HD SOURCE="HD3">§ 170.315(f)(1) Immunization Registries—Bidirectional Exchange</HD>
                    <P>We propose to revise the current certification criterion located in § 170.315(f)(1) “Transmission to immunization registries” to reference the most current HL7® Version 2.5.1 Implementation Guide for Immunization Messaging, Release 2.0 to enable systems to respond to incoming, patient-level queries from external systems. Specifically, we propose to update the standard in § 170.205(e)(4) to the HL7 v2.5.1 Implementation Guide for Immunization Messaging, Release 1.5, Published October 2018, which is a compilation of the Release 1.5 version and the Addendum from 2015 referenced in the current Program, and incorporate it by reference in § 170.299. Additionally, we are proposing to update the vocabulary standards in § 170.207(e)(3) and § 170.207(e)(4) referenced in § 170.315(f)(1)(i) to their newest versions.</P>
                    <P>
                        Additionally, we propose to add a functional requirement in § 170.315(f)(1)(C) to enable certified health IT to respond to incoming patient-level, immunization-specific queries from external systems. We propose a requirement in support of requests for multiple patients' data as a group using an Application Programming Interface in § 170.315(g)(20)(ii). Lastly, we propose 
                        <PRTPAGE P="63694"/>
                        to revise the name of the certification criterion in § 170.315(f)(1) to “Immunization registries—Bidirectional exchange” to more accurately represent the capabilities included in the certification criterion.
                    </P>
                    <HD SOURCE="HD3">Costs</HD>
                    <P>This section describes the estimated costs of meeting the requirements in the proposed updates to § 170.315(f)(1). These tasks have their own level of effort, and these estimates are detailed in Table 31 below and are based on the following assumptions:</P>
                    <P>1. Health IT developers will use the same labor costs and data models. Table 24 shows the estimated labor costs per product to meet the proposed requirements in § 170.315(f)(1). 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>2. We estimate that 177 products certified by 147 developers will be affected by our proposal. These estimates are a subset of the total estimated number of health IT developers and certified products we estimated above. The estimate of 177 products certified by 147 developers is derived as follows. We estimate that, in total, 387 health IT developers will certify 521 health IT products impacted by this rulemaking. However, not all these developers and products certify to § 170.315(f)(1) certification criterion and need to meet the proposed requirements. As of the end of 2022, 38% of developers and 34% of products certified to § 170.315(f)(1) certification criterion. We applied this modifier to our total developer and product estimate as an overall estimate of the number of developers and products impacted by the proposed modifications to the certification criterion.</P>
                    <P>
                        3. According to the May 2022 BLS occupational employment statistics, the mean hourly wage for a “Software Developer” is $63.91.
                        <SU>341</SU>
                        <FTREF/>
                         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 $127.82.
                    </P>
                    <FTNT>
                        <P>
                            <SU>341</SU>
                             
                            <E T="03">https://www.bls.gov/oes/current/oes151252.htm.</E>
                        </P>
                    </FTNT>
                    <BILCOD>BILLING CODE 4150-45-P</BILCOD>
                    <GPH SPAN="3" DEEP="493">
                        <PRTPAGE P="63695"/>
                        <GID>EP05AU24.029</GID>
                    </GPH>
                    <GPH SPAN="3" DEEP="229">
                        <PRTPAGE P="63696"/>
                        <GID>EP05AU24.030</GID>
                    </GPH>
                    <BILCOD>BILLING CODE 4150-45-C</BILCOD>
                    <P>The cost to a health IT developer to meet the proposed requirements in § 170.315(f)(1) would range from $95,865 to $319,550 per product, on average. This would be a one-time cost to developers per product that is certified to the specified certification criterion and would not be perpetual. Assuming 177 products overall and a labor rate of $127.82 per hour, we estimate that the total cost for all products would, on average, range from $17 to $56.6 million. Assuming 147 health IT developers, this would be an average cost per developer ranging from $115,429 to $384,764.</P>
                    <HD SOURCE="HD3">Benefits</HD>
                    <P>
                        The proposed updates have a wide range of benefits for end-users of health IT (such as physicians, pharmacists, public health practitioners) and the patient populations they serve by helping remove long-standing barriers to public health data interoperability, which in turn, will improve public health response and the nation's healthcare system, enabling better-informed decision making, more comprehensive data analytics, and faster, more coordinated responses to public health threats and emergencies. Further, enabling greater flow of health information from EHRs to public health authorities using HL7® FHIR®-based standards could allow public health to reduce burden and streamline data sharing while protecting patient privacy.
                        <SU>342</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>342</SU>
                             
                            <E T="03">https://www.cdc.gov/surveillance/pdfs/20_319521-D_DataMod-Initiative_901420.pdf.</E>
                        </P>
                    </FTNT>
                    <P>
                        The proposed revisions to § 170.315(f)(1), along with the proposed new § 170.315(f)(21) certification criterion that can be adopted by Health IT Modules supporting public health uses cases, would help advance complete, longitudinal immunization histories for individuals. Such comprehensive information would help close gaps that exist today as patients receive care from a variety of settings. This would support EHRs, IISs, and intermediaries in operating from the same foundational functionalities, and keep data moving with the speed of care. If an individual receives a vaccine from a pharmacy, from a community health fair, away from their home State, or at their provider's office, any approved user, regardless of their health IT system, should be able to have access to their complete, accurate vaccine history. According to the American Immunization Registry Association (AIRA), “the most important value of the IIS comes from providers' ability to query the IIS at the point of care and to locate and use the information about additional immunizations administered elsewhere.” 
                        <SU>343</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>343</SU>
                             AIRA Adult IIS Literature Review (
                            <E T="03">immregistries.org</E>
                            ), p.23.
                        </P>
                    </FTNT>
                    <P>
                        The proposed revisions to the certification criterion in § 170.315(f)(1) would help improve interoperability for immunization reporting across the major health IT systems involved and establish a shared technical foundation for health IT systems, with common capabilities related to exchange, receipt, query, and access. The reference and requirement of updated HL7 standards would help systems have more complete data, including demographic data like race and ethnicity, and that they have the functionality to send that data to other certified systems. HL7® message transmission from health care systems to IIS has been shown to improve timeliness and completeness of immunization data over manual entry.
                        <SU>344</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>344</SU>
                             Ibid, p.15.
                        </P>
                    </FTNT>
                    <P>While the benefits of these updates are not quantifiable at this time, we expect the proposed updates to significantly benefit end users of health IT and the patient populations they serve. Specifically, the standards update, and new requirements will enable greater flow of health information from EHRs to public health authorities which would result in increased public health data interoperability between health care and public health and enable better healthcare and public health decision making.</P>
                    <HD SOURCE="HD3">§ 170.315(f)(2) Syndromic Surveillance—Transmission to Public Health Agencies</HD>
                    <P>
                        We propose to revise the current certification criterion located in § 170.315(f)(2) “Transmission to public health agencies—syndromic surveillance”. We propose to revise the standard in § 170.205(d) (1), which is referenced in § 170.315(f)(2), to reference the most recent IG, HL7 Version 2.5.1 Implementation Guide: Syndromic Surveillance, Release 1—US Realm Standard for Trial Use, July 2019, and incorporate it by reference in § 170.299. We further propose to minimally change the name of the 
                        <PRTPAGE P="63697"/>
                        certification criterion in § 170.315(f)(2) to “Syndromic surveillance—Transmission to public health agencies.”
                    </P>
                    <HD SOURCE="HD3">Costs</HD>
                    <P>This section describes the estimated costs of meeting requirements in the proposed update to § 170.315(f)(2), which are detailed in Table 33 below and are based on the following assumptions:</P>
                    <P>1. Health IT developers will use the same labor costs and data models. Table 26 shows the estimated labor costs per product to make the proposed updates in § 170.315(f)(2). 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 the tables below.</P>
                    <P>2. We estimate that 141 products certified by 112 developers will be affected by our proposal. These estimates are a subset of the total estimated health IT developers and certified products we estimated above. The estimate of 141 products certified by 112 developers is derived as follows. We estimate that, in total, 387 health IT developers will certify 521 health IT products impacted by this rulemaking. However, not all these developers and products certify § 170.315(f)(2) and need to meet the proposed requirements. As of the end of 2022, 29% of developers and 27% of products certified § 170.315(f)(2). 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 certification criterion.</P>
                    <P>
                        3. According to the May 2022 BLS occupational employment statistics, the mean hourly wage for a “Software Developer” is $63.91.
                        <SU>345</SU>
                        <FTREF/>
                         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 $127.82.
                    </P>
                    <FTNT>
                        <P>
                            <SU>345</SU>
                             
                            <E T="03">https://www.bls.gov/oes/current/oes151252.htm.</E>
                        </P>
                    </FTNT>
                    <GPH SPAN="3" DEEP="243">
                        <GID>EP05AU24.031</GID>
                    </GPH>
                    <GPH SPAN="3" DEEP="171">
                        <GID>EP05AU24.032</GID>
                    </GPH>
                    <PRTPAGE P="63698"/>
                    <P>The cost to a health IT developer to meet the proposed requirements in § 170.315(f)(2) would range from $0 to $63,910 per product, on average. This would be a one-time cost to developers per product that is certified to the specified certification criterion and would not be perpetual. Assuming 141 products overall and a labor rate of $127.82 per hour, we estimate that the total cost for all products would, on average, range from $0 to $9 million. Assuming 112 health IT developers, this would be an average cost per developer ranging from $0 to $80,458.</P>
                    <HD SOURCE="HD3">Benefits</HD>
                    <P>The proposed updates have a wide range of benefits for end-users of health IT (such as physicians, pharmacists, public health practitioners) and the patient populations they serve by helping remove long-standing barriers to public health data interoperability, which in turn, will improve public health response and the nation's healthcare system, enabling better-informed decision making, more comprehensive data analytics, and faster, more coordinated responses to public health threats and emergencies.</P>
                    <P>
                        Syndromic surveillance data, when received in a timely manner and in a standard format, helps public health agencies achieve several surveillance goals including identifying emerging conditions or the long-term effects of unplanned mass-events and monitoring infectious disease to predict spikes.
                        <SU>346</SU>
                        <FTREF/>
                         The proposed revisions to the certification criterion in § 170.315(f)(2) would provide additional information, such as patients' acuity and comorbidities, for public health agencies to inform assessment of emerging threats to public health and identify possible outbreaks of infectious disease. Additionally, the observation component within the implementation guide now contains additional required elements relevant to public health surveillance that were previously optional including, but not limited to, pregnancy status, travel history, and acuity which aid in public health assessment, particularly in identification of emerging public health threats and the proceeding action. These revisions to the certification criterion in § 170.315(f)(2) would help with more needed data elements being shared with syndromic surveillance programs through use of the current HL7 IG, and that all syndromic surveillance systems can accept and validate incoming data. The new HL7 IG represents “a more refined and extensible product that can support syndromic surveillance activities across a wider and more diverse range of clinical venues, EHR implementations, and public health authorities.” 
                        <SU>347</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>346</SU>
                             Overview | NSSP | CDC.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>347</SU>
                             
                            <E T="03">https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6606111/.</E>
                        </P>
                    </FTNT>
                    <P>While the benefits of these updates are not quantifiable at this time, we expect the proposed updates to significantly benefit end users of health IT and the patient populations they serve. Specifically, the standards update would enable capture of critical data elements and facilitate public health data interoperability between health care and public health, which will enable better healthcare and public health decision making.</P>
                    <HD SOURCE="HD3">§ 170.315(f)(3) Reportable Laboratory Results—Transmission to Public Health Agencies—and Laboratory Orders—Receive and Validate</HD>
                    <P>We propose to revise the current certification criteria located in § 170.315(f)(3) Transmission to public health agencies—reportable laboratory tests and values/results. The certification criterion currently only includes transmission of lab results and does not cover functions related to the laboratory order. We propose to update the certification criterion to also include functionality for certified health IT to receive, validate, parse, and filter laboratory orders, according to the standard in § 170.205(g)(2). We also propose to update the standard referred to in § 170.205(g)(3) for the transmission of laboratory results.</P>
                    <P>We propose to adopt the standard for HL7 Version 2.5.1 Implementation Guide: Laboratory Orders (LOI) from EHR, Release 1, STU Release 4—US Realm (LOI) in § 170.205(g)(2) and incorporate it by reference in § 170.299, and to also adopt in § 170.205(g)(3)—and incorporate by reference in § 170.299—the standard for HL7 Version 2.5.1 Implementation Guide: Laboratory Results Interface, Release 1 STU Release 4—US Realm (LRI), and to specify the use of the Public Health Profile, in addition to the ELR IG.</P>
                    <P>We propose to revise § 170.315(f)(3)(i) to reference LRI in addition to the HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health, Release 1 (US Realm) (ELR). We propose to revise the standards in § 170.207(a), (c), and (m), which are referenced in § 170.315(f)(3)(i) and § 170.315(f)(3)(ii), to reference the latest versions of SNOMED CT®, LOINC®, and UCUM, respectively.</P>
                    <P>We further propose to add a functional requirement in § 170.315(f)(3)(iii) requiring the ability to receive, validate, parse, and filter reportable laboratory orders according to the standard proposed in § 170.205(g)(2). Additionally, we propose to rename the certification criterion in § 170.315(f)(3) to “Reportable laboratory results—Transmission to public health agencies—and Laboratory Orders—Receive and validate.”</P>
                    <HD SOURCE="HD3">Costs</HD>
                    <P>This section describes the estimated costs of meeting the requirements in the proposed updates to § 170.315(f)(3). These tasks have their own level of effort, and these estimates are detailed in Table 35 below and are based on the following assumptions:</P>
                    <P>1. Health IT developers will use the same labor costs and data models. Table 28 shows the estimated labor costs per product to meet the proposed requirements in § 170.315(f)(3). 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 the tables below.</P>
                    <P>2. We estimate that 47 products certified by 39 developers will be affected by our proposal. These estimates are a subset of the total estimated health IT developers and certified products we estimated above. The estimate of 47 products certified by 39 developers is derived as follows. We estimate that, in total, 387 health IT developers will certify 521 health IT products impacted by this rulemaking. However, not all these developers and products certify § 170.315(f)(3) and need to meet the proposed requirements. As of the end of 2022, 10% of developers and 9% of products certified § 170.315(f)(3). 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 certification criterion.</P>
                    <P>
                        3. According to the May 2022 BLS occupational employment statistics, the mean hourly wage for a “Software Developer” is $63.91.
                        <SU>348</SU>
                        <FTREF/>
                         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 $127.82.
                    </P>
                    <FTNT>
                        <P>
                            <SU>348</SU>
                             
                            <E T="03">https://www.bls.gov/oes/current/oes151252.htm.</E>
                        </P>
                    </FTNT>
                    <BILCOD>BILLING CODE 4150-45-P</BILCOD>
                    <GPH SPAN="3" DEEP="640">
                        <PRTPAGE P="63699"/>
                        <GID>EP05AU24.033</GID>
                    </GPH>
                    <GPH SPAN="3" DEEP="259">
                        <PRTPAGE P="63700"/>
                        <GID>EP05AU24.034</GID>
                    </GPH>
                    <BILCOD>BILLING CODE 4150-45-C</BILCOD>
                    <P>The cost to a health IT developer to meet the proposed requirements in § 170.315(f)(3) would range from $255,640 to $830,830 per product, on average. This would be a one-time cost to developers per product that is certified to the specified certification criterion and would not be perpetual. Assuming 47 products overall and a labor rate of $127.82 per hour, we estimate that the total cost for all products would, on average, range from $12 to $39 million. Assuming 39 health IT developers, this would be an average cost per developer ranging from $308,079 to $1,001,257.</P>
                    <HD SOURCE="HD3">Benefits</HD>
                    <P>
                        The proposed updates have a wide range of benefits for end-users of health IT (such as physicians, laboratories, public health practitioners) and the patient populations they serve by helping remove long-standing barriers to public health data interoperability, which in turn, will improve public health response and the nation's healthcare system, enabling better-informed decision making and faster, more coordinated responses to public health threats and emergencies. Laboratory standards are critical not only for health care and public health to be able to exchange and have a common understanding of results with identical meanings that are often represented in different formats, but also for patients who can view test results in their online portals.
                        <SU>349</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>349</SU>
                             Development and Implementation of a Standard Format for Clinical Laboratory Test Results | American Journal of Clinical Pathology | Oxford Academic (
                            <E T="03">oup.com</E>
                            ).
                        </P>
                    </FTNT>
                    <P>
                        The proposed changes to the certification criterion in § 170.315(f)(3) would help increase the data shared between health care providers, laboratories, and public health agencies, and would increase interoperability among the different systems in place at each entity. To encompass all aspects of the laboratory workflow, the proposed requirements in § 170.315(f)(3) to create and transmit laboratory orders according to the LOI IG and receive laboratory results according to the LRI IG align with the proposed updates to § 170.315(a)(2), 
                        <E T="03">Computerized provider order entry—laboratory</E>
                         and the new proposed requirements in § 170.315(f)(23) for public health agencies to be able to receive electronically transmitted laboratory values/results in their system(s) according to the LRI IG. Together, these proposals will help ensure that laboratory results and orders are sent and received according to the same standards and that all systems involved in the workflow have the same baseline functionality. By requiring systems to receive results and values back electronically (according to national standards), more complete patient information will be available to clinicians throughout the laboratory workflow and for public health action.
                    </P>
                    <P>With the addition of lab orders to values/results in § 170.315(f)(3), there would be another data source—often that is collected at the point of care from the patient—which would contribute to more complete and accurate demographic information important to understanding and addressing health disparities. Our proposed changes would also provide more complete patient-level information for contact tracing, patient outreach, direct care, and other clinical and public health activities. The use of the LRI IG would provide more specificity than ELR, which can decrease the need for one-off mapping. Additionally, the LRI and LOI IGs could have uses beyond public health reporting, which would reduce implementation and maintenance burden for reporters. Both the LOI and LRI standards have multiple use cases defined in the IGs, allowing for more flexibility, reusability, and scalability.</P>
                    <P>
                        Standards adoption would aid in getting more complete information to public health agencies, as LOI makes important patient demographic information required, including race, ethnicity, sex, and contact information, as well as Ask at Order Entry questions (AOEs). In one study, COVID electronic laboratory reports were missing data on race more than one-third of the time and data on ethnicity were present less than one-fifth of the time.
                        <SU>350</SU>
                        <FTREF/>
                         Missing data in 
                        <PRTPAGE P="63701"/>
                        laboratory results transmitted to public health authorities also remains a problem. Having more complete demographic information, enabled by the increased specificity of the LOI and LRI standards, can help improve patient matching, which in turn would improve patient care and the efficiency of care.
                    </P>
                    <FTNT>
                        <P>
                            <SU>350</SU>
                             Electronic health information quality challenges and interventions to improve public health surveillance data and practice.—Abstract—Europe PMC
                        </P>
                    </FTNT>
                    <P>While the benefits of many of these modifications are not quantifiable at this time, we expect the proposed changes to help increase the data shared between health care providers, laboratories, and public health agencies, and would increase interoperability among the different systems in place at each entity. Our proposed changes would also provide more complete patient-level information for contact tracing, patient outreach, direct care, and other clinical and public health activities.</P>
                    <HD SOURCE="HD3">§ 170.315(f)(4) Cancer Registry Reporting—Transmission to Public Health Agencies</HD>
                    <P>We propose to modify the requirement for a certified Health IT Module to support creation and submission of cancer case information in § 170.315(f)(4) using at least one of the following standards:</P>
                    <P>• The cancer FHIR® reporting bundle and accompanying profiles according to the HL7® FHIR® Central Cancer Registry Reporting Content IG in § 170.205(i)(3), with requirement that all data elements indicated as “mandatory” and “must support” within the IG by the standards and implementation specifications must be supported, and/or</P>
                    <P>• The HL7 CDA® Release 2 Implementation Guide: Reporting to Public Health Cancer Registries from Ambulatory Healthcare Providers, Release 1, DSTU Release 1.1—U.S. Realm. in § 170.205(i)(2).</P>
                    <P>We also propose the inclusion of an additional requirement within the cancer registry reporting certification criterion, to include cancer pathology reporting. We propose to adopt the standard HL7® FHIR® Cancer Pathology Data Sharing, 1.0.0—STU1 in § 170.205(i)(4) and incorporate it by reference in § 170.299. We also propose to revise § 170.315(f)(4) to add a requirement to create and transmit cancer pathology laboratory values and results in accordance with the proposed standard referenced in § 170.205(i)(4), Cancer Pathology Data Sharing, 1.0.0—STU1, including support for all “mandatory” and “must support” data elements within the IG. We also propose minimal changes to the name of this certification criterion to, “Cancer registry reporting—Transmission to public health agencies.”</P>
                    <HD SOURCE="HD3">Costs</HD>
                    <P>This section describes the estimated costs of meeting the requirements in the proposed updates to § 170.315(f)(4). These tasks have their own level of effort, and these estimates are detailed in Table 37 below and are based on the following assumptions:</P>
                    <P>1. Health IT developers will use the same labor costs and data models. Table 30 shows the estimated labor costs per product to meet the proposed requirements in § 170.315(f)(4). 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 the tables below.</P>
                    <P>2. We estimate that 42 products certified by 35 developers will be affected by our proposal. These estimates are a subset of the total estimated health IT developers and certified products we estimated above. The estimate of 42 products certified by 35 developers is derived as follows. We estimate that, in total, 387 health IT developers will certify 521 health IT products impacted by this rulemaking. However, not all these developers and products certify § 170.315(f)(4) and need to meet the proposed requirements. As of the end of 2022, 9% of developers and 8% of products certified § 170.315(f)(4). 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 certification criterion.</P>
                    <P>
                        3. According to the May 2022 BLS occupational employment statistics, the mean hourly wage for a “Software Developer” is $63.91.
                        <SU>351</SU>
                        <FTREF/>
                         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 $127.82.
                    </P>
                    <FTNT>
                        <P>
                            <SU>351</SU>
                             
                            <E T="03">https://www.bls.gov/oes/current/oes151252.htm</E>
                            .
                        </P>
                    </FTNT>
                    <BILCOD>BILLING CODE 4150-45-P</BILCOD>
                    <GPH SPAN="3" DEEP="465">
                        <PRTPAGE P="63702"/>
                        <GID>EP05AU24.035</GID>
                    </GPH>
                    <GPH SPAN="3" DEEP="200">
                        <PRTPAGE P="63703"/>
                        <GID>EP05AU24.036</GID>
                    </GPH>
                    <BILCOD>BILLING CODE 4150-45-C</BILCOD>
                    <P>The cost to a health IT developer to meet the proposed requirements in § 170.315(f)(4) would range from $63,910 to $191,730 per product, on average. This would be a one-time cost to developers per product that is certified to the specified certification criterion and would not be perpetual. Assuming 42 products overall and a labor rate of $127.82 per hour, we estimate that the total cost for all products would, on average, range from $2.7 to $8 million. Assuming 35 health IT developers, this would be an average cost per developer ranging from $76,692 to $230,076.</P>
                    <HD SOURCE="HD3">Benefits</HD>
                    <P>
                        The proposed updates have a wide range of benefits for end-users of health IT (such as physicians, laboratory technicians, public health practitioners) and the patient populations they serve. Collectively, proposed revisions to existing (f) certification criteria help remove long-standing barriers to public health data interoperability, which in turn, will improve public health response and the nation's healthcare system, enabling better-informed decision making, more comprehensive data analytics, and faster, more coordinated responses to public health threats and emergencies. Further, enabling greater flow of health information from EHRs to public health authorities using HL7 FHIR-based standards could allow public health to streamline of data sharing while protecting patient privacy.
                        <SU>352</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>352</SU>
                             
                            <E T="03">https://www.cdc.gov/surveillance/pdfs/20_319521-D_DataMod-Initiative_901420.pdf.</E>
                        </P>
                    </FTNT>
                    <P>
                        Adopting FHIR standards for cancer registry reporting would help automate and accelerate reporting to central cancer registries and ensure that cancer data are collected in a complete and consistent manner that would facilitate exchange.
                        <SU>353</SU>
                        <FTREF/>
                         Manual and non-standardized data collection can lead to missing or low-quality, non-comparable data, making it difficult to share information needed to facilitate public health surveillance and research. Standards-based reporting to cancer registries supports faster and more accurate reporting, makes the data more useful for secondary purposes, and facilitates bi-directional communication when supplemental data are needed for research or treatment purposes.
                        <SU>354</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>353</SU>
                             Next Generation of Central Cancer Registries | JCO Clinical Cancer Informatics (
                            <E T="03">ascopubs.org</E>
                            ).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>354</SU>
                             Ibid.
                        </P>
                    </FTNT>
                    <P>
                        An important component of diagnosing cancer, and particularly in understanding how advanced cases are at the point of diagnosis, is cancer pathology reporting. The information included in cancer pathology reports are critical sources of data for cancer registries as the vast majority of cancer cases are diagnosed using methods that generate a pathology report.
                        <SU>355</SU>
                        <FTREF/>
                         The proposed updates to the certification criterion in § 170.315(f)(4) for cancer registry reporting would help ensure public health agencies receive standardized, electronic pathology reports, which would be an important addition to more complete and accurate understanding of cancer diagnoses and assessing the stage at diagnosis. The IG leverages structured data capture approaches developed by various stakeholders including the College of American Pathologists, NAACCR, and the IHE SDC on FHIR resources, which is important for promoting interoperability, sustainability, and for scaling standards adoption.
                        <SU>356</SU>
                        <FTREF/>
                         The inclusion of electronic transmission of cancer pathology reporting in the Program will result in more complete, accurate diagnostic information being sent, according to a shared standard, to State cancer registries. Such information can better inform cancer staging and aid in targeted programming where it is most needed.
                    </P>
                    <FTNT>
                        <P>
                            <SU>355</SU>
                             Using informatics to improve cancer surveillance—PMC (
                            <E T="03">nih.gov</E>
                            ).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>356</SU>
                             Ibid.
                        </P>
                    </FTNT>
                    <P>
                        While the benefits of many of these modifications are not quantifiable at this time, we expect the resulting improvements from standards adoption to promote interoperable exchange of more complete and accurate cancer data between health care providers and public health which will allow for better public health decision-making and evaluation of program interventions aimed at cancer prevention and early detection. Health IT users will benefit from the updates to the standard through increased efficiency of reporting (
                        <E T="03">e.g.,</E>
                         automation enabled by standardization), which will reduce the time burden of mandatory reporting. 
                    </P>
                    <PRTPAGE P="63704"/>
                    <FP>
                        Standardized capture of cancer data will also allow clinicians to more readily identify information needed to make decisions about their patients' care and treatment.
                        <SU>357</SU>
                        <FTREF/>
                         Thus, patients will benefit from more complete data being captured and used by clinicians to make decisions about their care. These data can also be used by public health agencies to improve population health by identifying high-risk groups, providing targeted screening, and investigating underlying causes of cancer.
                        <SU>358</SU>
                        <FTREF/>
                    </FP>
                    <FTNT>
                        <P>
                            <SU>357</SU>
                             Using informatics to improve cancer surveillance—PMC (
                            <E T="03">nih.gov</E>
                            ).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>358</SU>
                             Ibid.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">§ 170.315(f)(5) Transmission to Public Health Agencies—Electronic Case Reporting</HD>
                    <P>We propose to revise the certification criterion in § 170.315(f)(5) to require adherence to the HL7 FHIR eCR IG only adopted in § 170.205(t)(1). We propose to maintain in § 170.205(t)(1) adherence to specific aspects of the HL7 FHIR eCR IG to allow for flexibility: the electronic initial case report (eICR) profiles and the RR profile of the HL7 FHIR eCR IG, and the ability to consume and process electronic case reporting trigger codes and identify a reportable patient visit or encounter based on a match from the Reportable Conditions Trigger Code value set as specified in the HL7 FHIR eCR IG. We propose that Health IT Modules must enable a user to: create a case report for electronic transmission in accordance with the following:</P>
                    <P>(A) Consume and process electronic case reporting trigger codes and identify a reportable patient visit or encounter based on a match from the Reportable Conditions Trigger Code (RCTC) value set as specified in the HL7 FHIR eCR IG in § 170.205(t)(1).</P>
                    <P>(B) Create a case report consistent with the eICR profile of the HL7 FHIR eCR IG in § 170.205(t)(1)</P>
                    <P>(C) Receive, consume, and process a case report response that is formatted to the reportability response profile of the HL7 FHIR eCR IG in § 170.205(t)(1).</P>
                    <P>(D) Transmit a case report electronically to a system capable of receiving an electronic case report.</P>
                    <HD SOURCE="HD3">Costs</HD>
                    <P>This section describes the estimated costs of meeting the requirements in the proposed updates to § 170.315(f)(5). These tasks have their own level of effort, and these estimates are detailed in Table 39 below and are based on the following assumptions:</P>
                    <P>1. Health IT developers will use the same labor costs and data models. Table 32 shows the estimated labor costs per product to meet the proposed requirements in § 170.315(f)(5). 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 the tables below.</P>
                    <P>2. We estimate that a total of 196 products certified by 162 developers will be affected by our proposal. These estimates are a subset of the total estimated health IT developers and certified products we estimated above. We estimate that, in total, 387 health IT developers will certify 521 health IT products impacted by this rulemaking. However, not all these developers and products certify § 170.315(f)(5) and need to meet the proposed requirements. The estimate of 196 products certified by 162 developers is derived from the total number of products that were estimated to be affected by updates to the eCR certification criterion in the HTI-1 Final Rule (55 products that were currently certified by 48 developers in 2021 plus 141 new products expected to be certified by 114 developers for the first time).</P>
                    <P>
                        3. According to the May 2022 BLS occupational employment statistics, the mean hourly wage for a “Software Developer” is $63.91.
                        <SU>359</SU>
                        <FTREF/>
                         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 $127.82.
                    </P>
                    <FTNT>
                        <P>
                            <SU>359</SU>
                             
                            <E T="03">https://www.bls.gov/oes/current/oes151252.htm</E>
                            .
                        </P>
                    </FTNT>
                    <GPH SPAN="3" DEEP="341">
                        <PRTPAGE P="63705"/>
                        <GID>EP05AU24.037</GID>
                    </GPH>
                    <GPH SPAN="3" DEEP="200">
                        <GID>EP05AU24.038</GID>
                    </GPH>
                    <P>The cost to a health IT developer to meet the proposed requirements in § 170.315(f)(5) would range from $0 to $383,460 per product, on average. This would be a one-time cost to developers per product that is certified to the specified certification criterion and would not be perpetual. Assuming 196 products overall and a labor rate of $127.82 per hour, we estimate that the total cost to all health IT developers would, on average, range from $0 to $75 million. Assuming 162 health IT developers, this would be an average cost per developer ranging from $0 to $463,939.</P>
                    <HD SOURCE="HD3">Benefits</HD>
                    <P>
                        The proposed updates have a wide range of benefits for end-users of health IT (such as physicians, pharmacists, public health practitioners) and the patient populations they serve. Collectively, proposed revisions to existing (f) certification criteria help remove long-standing barriers to public health data interoperability, which in turn, will improve public health response and the nation's healthcare system, enabling better-informed 
                        <PRTPAGE P="63706"/>
                        decision making, more comprehensive data analytics, and faster, more coordinated responses to public health threats and emergencies. Further, enabling greater flow of health information from EHRs to public health authorities using HL7 FHIR-based standards could allow public health to take advantage of advanced data science capabilities such as predictive analysis, enhanced surveillance, personalized communications, and streamlining of data sharing while protecting patient privacy.
                        <SU>360</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>360</SU>
                             Public Health Data Modernization Executive Summary (
                            <E T="03">cdc.gov</E>
                            ).
                        </P>
                    </FTNT>
                    <P>
                        Important benefits of adopting standards-based requirements for electronic case reporting include improved consistency of reporting specific data elements, increased efficiency of exchange (
                        <E T="03">e.g.,</E>
                         by facilitating automated reporting), and greater public health data interoperability between health care and public health. Case reporting provides critical information to track communicable diseases, but manual processes have historically been “slow, incomplete, and burdensome for healthcare and public health personnel.” 
                        <SU>361</SU>
                        <FTREF/>
                         Increasing connectivity through eCR “can result in more accurate, complete, and timely data to support public health action”.
                        <SU>362</SU>
                        <FTREF/>
                         In turn, more timely detection of health-related conditions or events of public concern can result in rapid intervention and lowered disease transmission.
                        <SU>363</SU>
                         
                        <SU>364</SU>
                        <FTREF/>
                         More thorough reporting can also improve targeted interventions to improve health of vulnerable populations.
                        <SU>365</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>361</SU>
                             
                            <E T="03">digital-bridge-ecr-evaluation-report-12-32019.pdf</E>
                             (
                            <E T="03">aimsplatform.org</E>
                            ).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>362</SU>
                             Ibid.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>363</SU>
                             The Promise of Electronic Case Reporting—PubMed (
                            <E T="03">nih.gov</E>
                            ).
                        </P>
                        <P>
                            <SU>364</SU>
                             Public Health Agencies (
                            <E T="03">aimsplatform.org</E>
                            ).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>365</SU>
                             
                            <E T="03">digital-bridge-ecr-evaluation-report-12-32019.pdf</E>
                             (
                            <E T="03">aimsplatform.org</E>
                            ).
                        </P>
                    </FTNT>
                    <P>
                        Automated case reporting from healthcare to public health reduces the burden of required reporting for providers while improving the timeliness, accuracy, and completeness of case reports to support public health preparedness and response.
                        <E T="51">366 367</E>
                        <FTREF/>
                         One pilot found providers spent 2.4 seconds to transmit cases electronically, compared to 4.22 minutes manually.
                        <SU>368</SU>
                        <FTREF/>
                         To the extent case reporting happens automatically, it would also improve clinical care by allowing providers to focus on the medical needs of their patients without having to shift to consider related public health reporting.
                        <SU>369</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>366</SU>
                             Improving Notifiable Disease Case Reporting Through Electronic Information Exchange-Facilitated Decision Support: A Controlled Before-and-After Trial—PubMed (
                            <E T="03">nih.gov</E>
                            ).
                        </P>
                        <P>
                            <SU>367</SU>
                             A Modified Public Health Automated Case Event Reporting Platform for Enhancing Electronic Laboratory Reports with Clinical Data: Design and Implementation Study—PubMed (
                            <E T="03">nih.gov</E>
                            ).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>368</SU>
                             Piloting Electronic Case Reporting for Improved Surveillance of Sexually Transmitted Diseases in Utah—PMC (
                            <E T="03">nih.gov</E>
                            )/.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>369</SU>
                             Public Health Agencies (
                            <E T="03">aimsplatform.org</E>
                            ).
                        </P>
                    </FTNT>
                    <P>
                        Requiring a single standard will help drive the industry and community at large to address issues within the standard and move towards adoption of a common standard for electronic case reporting. The use of FHIR-based solutions encourages more flexibility and reduced burden for set-up and maintenance and aligns with CDC's Public Health Data Strategy. The Public Health Data Strategy prioritizes electronic case reporting, particularly via mechanisms that reduce burden and encourage more complete and timely data exchange.
                        <SU>370</SU>
                        <FTREF/>
                         Adopting a common standard for case reporting would ensure case report information can be efficiently exchanged between healthcare and public health in the right format, through the right channel at the right time.
                        <SU>371</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>370</SU>
                             
                            <E T="03">Public_Health_Data_Strategy-final-P.pdf</E>
                             (
                            <E T="03">cdc.gov</E>
                            ) 
                            <E T="03">Public_Health_Data_Strategy-final-P.pdf</E>
                             (
                            <E T="03">cdc.gov</E>
                            ).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>371</SU>
                             Public Health Data Interoperability (
                            <E T="03">cdc.gov</E>
                            ).
                        </P>
                    </FTNT>
                    <P>
                        While the benefits of these updates are not quantifiable at this time, we expect the proposed updates to significantly benefit end users of health IT and the patient populations they serve. The standards update and new requirements would result in increased public health data interoperability between health care and public health, which will enable better healthcare and public health decision making. Specifically, standards-based electronic case reporting would enable automatic, complete, accurate data to be reported in real-time to public health agencies which facilitates evidence-based decision-making for public health and reduces burden for health care providers. This would simultaneously support public health response efforts while reducing the time burden for providers to report. Standards-based reporting also streamlines required reporting to multiple jurisdictions and facilitates bi-directional communication between providers and public health.
                        <SU>372</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>372</SU>
                             Public Health Surveillance:—PMC (
                            <E T="03">nih.gov</E>
                            ).
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">§ 170.315(f)(6) Antimicrobial Use and Resistance Reporting—Transmission to Public Health Agencies</HD>
                    <P>We propose to revise the current certification criteria located in § 170.315(f)(6) Transmission to public health agencies—antimicrobial use and resistance reporting. We propose to update the standard listed in § 170.205(r) to HL7 CDA® R2 Implementation Guide: Healthcare Associated Infection (HAI) Reports, Release 3—US Realm for two specific components of the IG, detailed below, and incorporate it by reference in § 170.299. The two required sections updated in the IG are: HAI Antimicrobial Use and Resistance (AUR) Antimicrobial Resistance Option (ARO) Report (V5) specific document template in Section 1.1.14; and Antimicrobial Resistance Option (ARO) Summary Report (V3) specific document template in Section 1.1.2, which have already been advanced for voluntary adoption under ONC's Standards Version Advancement Process (SVAP). We are not proposing an update to the Antimicrobial Use (AUP) Summary Report (Numerator and Denominator), currently included in the criteria. We also propose minimal changes to the name of this certification criterion to, “Antimicrobial use and resistance reporting—Transmission to public health agencies.”</P>
                    <HD SOURCE="HD3">Costs</HD>
                    <P>This section describes the estimated costs of meeting requirements in the proposed update to § 170.315(f)(6), which are detailed in Table 41 below and are based on the following assumptions:</P>
                    <P>1. Health IT developers will use the same labor costs and data models. Table 34 shows the estimated labor costs per product to make the proposed updates in § 170.315(f)(6). We recognize that health IT developer costs will vary; however, our estimates in this section assume all health IT developers will incur the costs in the tables below.</P>
                    <P>
                        2. The number of products that will update to the revised AUR certification criterion is estimated based on the total number of currently certified products plus the number of new products we expect to certify to the certification criterion. Both estimates are adjusted for attrition. We estimate that, in total, 387 health IT developers will certify 521 health IT products impacted by this rulemaking. However, not all these developers and products certify § 170.315(f)(6) and need to meet the proposed requirements. As of the end of 2022, 4% of developers and 5% of 
                        <PRTPAGE P="63707"/>
                        products certified § 170.315(f)(6). Applying this modifier to our total developer and product estimates, we estimate that 26 currently certified products by 15 developers will be affected by our proposal.
                    </P>
                    <P>In 2023, CMS finalized a requirement that eligible hospitals and critical access hospitals participating in the Medicare Promoting Interoperability Program must begin reporting a new AUR Surveillance measure for Electronic Health Record (EHR) reporting periods in 2024. Due to this new program requirement, we expect more Health IT Modules to certify the AUR certification criterion in the coming year(s). As a proxy for possible future certification of AUR, we used the number of products that are currently certified to § 170.315(f)(3) (Transmission to public health agencies—reportable laboratory tests and values/results) to estimate future certification of the AUR certification criterion. As of 2022, 58% of developers and 67% of products certified to § 170.315(f)(3), but not § 170.315(f)(6). Using these rates, we estimate that 22 developers will newly certify 31 products impacted by this rulemaking.</P>
                    <P>Overall, we estimate updates to the AUR certification criterion will impact 31 products certified by 22 developers for the first time (“New”) and 26 products already certified by 15 developers (“Current”) for an estimated total of 57 products certified by 37 developers.</P>
                    <P>
                        3. According to the May 2022 BLS occupational employment statistics, the mean hourly wage for a “Software Developer” is $63.91.
                        <SU>373</SU>
                        <FTREF/>
                         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 $127.82.
                    </P>
                    <FTNT>
                        <P>
                            <SU>373</SU>
                             
                            <E T="03">https://www.bls.gov/oes/current/oes151252.htm</E>
                            .
                        </P>
                    </FTNT>
                    <BILCOD>BILLING CODE 4150-45-P</BILCOD>
                    <GPH SPAN="3" DEEP="550">
                        <PRTPAGE P="63708"/>
                        <GID>EP05AU24.039</GID>
                    </GPH>
                    <GPH SPAN="3" DEEP="295">
                        <PRTPAGE P="63709"/>
                        <GID>EP05AU24.040</GID>
                    </GPH>
                    <BILCOD>BILLING CODE 4150-45-C</BILCOD>
                    <P>The cost to a health IT developer to meet the proposed requirements in § 170.315(f)(6) would range from $127,820 to $191,730 for new products and $0 to $127,820 for currently certified products, on average. This would be a one-time cost to developers per product that is certified to the specified certification criterion and would not be perpetual. Assuming 57 products overall and a labor rate of $127.82 per hour, we estimate that the total cost to all health IT developers would, on average, range from $4 to $9.3 million. Assuming 37 health IT developers in total (22 developers for new products and 15 developers for currently certified products), this would be an average cost per developer ranging from $69,516 to $162,578.</P>
                    <HD SOURCE="HD3">Benefits</HD>
                    <P>The proposed updates have a wide range of benefits for end-users of health IT (such as physicians, pharmacists, public health practitioners) and the patient populations they serve. Collectively, proposed revisions to existing (f) certification criteria help remove long-standing barriers to public health data interoperability, which in turn, will improve public health response and the nation's healthcare system, enabling better-informed decision making, more comprehensive data analytics, and faster, more coordinated responses to public health threats and emergencies.</P>
                    <P>The monitoring of antimicrobial use and resistance is a vital component of public health reporting. The proposed updates to the certification criterion in § 170.315(f)(6) for antimicrobial use and resistance reporting can help facilitate timely reporting to public health agencies by reducing the burden for health care facilities to report. This in turn will allow prescribers to receive feedback regarding prescribing practices and improve the appropriate use of antimicrobials. Standards adoption can lead to more specific and complete information being shared with public health agencies, allowing for follow-up activities and research to address rising rates of antimicrobial resistance. The updated version includes new and updated reports, templates, and value sets that enable more advanced reports. These new and updated components provide additional contextual and clinical information for public health officials.</P>
                    <P>While the benefits of many of these modifications are not quantifiable at this time, we expect the updated IG to lead to more specific and complete information being shared with public health agencies, allowing for follow-up activities and research to address rising rates of antimicrobial resistance.</P>
                    <HD SOURCE="HD3">§ 170.315(f)(7) Health Care Surveys—Transmission to Public Health Agencies</HD>
                    <P>We propose to revise the current certification criteria located in § 170.315(f)(7) Transmission to public health agencies—health care surveys. We propose to update the standard for health care survey information for electronic transmission specified in § 170.205(s) to HL7 CDA® R2 Implementation Guide: National Health Care Surveys (NHCS), R1 STU Release 3.1—US Realm and incorporate it by reference in § 170.299. To advance the electronic transmission of health care surveys and include the relevant and needed information to achieve its intent, we propose this version of the standard, as it includes new and updated templates with important context. We also propose to minimally change the name of this certification criterion to, “Health care surveys—Transmission to public health agencies.”</P>
                    <HD SOURCE="HD3">Costs</HD>
                    <P>This section describes the estimated costs of meeting requirements in the proposed update to § 170.315(f)(7), which are detailed in Table 43 below and are based on the following assumptions:</P>
                    <P>
                        1. Health IT developers will use the same labor costs and data models. Table 36 shows the estimated labor costs per product to make the proposed updates in § 170.315(f)(7). We recognize that 
                        <PRTPAGE P="63710"/>
                        health IT developer costs will vary; however, our estimates in this section assume all health IT developers will incur the costs noted in the tables below.
                    </P>
                    <P>2. We estimate that 52 products certified by 43 developers will be affected by our proposal. These estimates are a subset of the total estimated health IT developers and certified products we estimated above. The estimate of 52 products certified by 43 developers is derived as follows. We estimate that, in total, 387 health IT developers will certify 521 health IT products impacted by this rulemaking. However, not all these developers and products certify § 170.315(f)(7) and need to meet the proposed requirements. As of the end of 2022, 11% of developers and 10% of products certified § 170.315(f)(7). 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 certification criterion.</P>
                    <P>
                        3. According to the May 2022 BLS occupational employment statistics, the mean hourly wage for a “Software Developer” is $63.91.
                        <SU>374</SU>
                        <FTREF/>
                         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 $127.82.
                    </P>
                    <FTNT>
                        <P>
                            <SU>374</SU>
                             
                            <E T="03">https://www.bls.gov/oes/current/oes151252.htm</E>
                            .
                        </P>
                    </FTNT>
                    <GPH SPAN="3" DEEP="257">
                        <GID>EP05AU24.041</GID>
                    </GPH>
                    <GPH SPAN="3" DEEP="175">
                        <GID>EP05AU24.042</GID>
                    </GPH>
                    <P>
                        The cost to a health IT developer to meet the proposed requirements in § 170.315(f)(7) would range from $63,910 to $127,820 per product, on average. This would be a one-time cost to developers per product that is certified to the specified certification criterion and would not be perpetual. Assuming 52 products overall and a labor rate of $127.82 per hour, we estimate that the total cost to all health IT developers would, on average, range 
                        <PRTPAGE P="63711"/>
                        from $3.3 to $6.6 million. Assuming 112 health IT developers, this would be an average cost per developer ranging from $77,287 to $154,573.
                    </P>
                    <HD SOURCE="HD3">Benefits</HD>
                    <P>The proposed updates have a wide range of benefits for end-users of health IT (such as physicians, pharmacists, public health practitioners) and the patient populations they serve. Collectively, proposed revisions to existing (f) certification criteria help remove long-standing barriers to public health data interoperability, which in turn, will improve public health response and the nation's healthcare system, enabling better-informed decision making, more comprehensive data analytics, and faster, more coordinated responses to public health threats and emergencies.</P>
                    <P>
                        Health care surveys help provide insight to inform policy, research, and quality, and sending them electronically allows for wider representation from hospitals and health care organizations, as well as reduces manual burden on the reporters.
                        <SU>375</SU>
                        <FTREF/>
                         Improving the process for electronic collection of survey data, including the use of standards, could make these important surveys easier to administer. Standards adoption will help advance the electronic transmission of health care surveys and include the relevant and needed information to achieve their intent. These additions and updates include, but are not limited to, revised sections for emergency department encounters, patient information sections, gender identity observation, and number of visits over the past 12 months. Such information will provide additional insight on trends in hospitalization, surveillance of symptomology and diagnoses, and demographics that can highlight disparities and better inform interventions.
                    </P>
                    <FTNT>
                        <P>
                            <SU>375</SU>
                             DHCS—National Health Care Surveys Homepage (
                            <E T="03">cdc.gov</E>
                            ).
                        </P>
                    </FTNT>
                    <P>While the benefits of many of these modifications are not quantifiable at this time, we expect the resulting improvements to interoperable exchange of health information to significantly benefit end users of health IT by making it easy to collect and report data for health care surveys. These updates will ultimately benefit patient populations as they data are used to inform efforts to improve quality of care, allocate health care resources, and eliminate disparities in the provision of health care services.</P>
                    <HD SOURCE="HD3">§ 170.315(f)(8) Birth Reporting—Transmission to Public Health Agencies</HD>
                    <P>We propose a new certification criterion in § 170.315(f)(8), Birth reporting—Transmission to public health agencies. As a part of this new certification criterion, we propose to adopt the HL7 FHIR standard Vital Records Birth and Fetal Death Reporting 1.1.0—STU 1.1 in § 170.205(v) for electronically submitting medical and health information from birth certificate reports to public health agencies.</P>
                    <HD SOURCE="HD3">Costs</HD>
                    <P>This section describes the estimated costs of meeting the proposed requirements in § 170.315(f)(8). Since this new certification criterion is not currently tied to any requirements, we estimate the costs for a single developer to voluntarily certify but do not assess industry wide costs associated with adoption. Thus, we estimate the number of labor hours that would be needed from a Health IT developer to perform each part of the proposed requirements for a given product. The level of effort associated with meeting requirements for a single product is detailed in Table 45 below and is based on the following assumptions:</P>
                    <P>1. Health IT developers will use the same labor costs and data models. Table 38 shows the estimated labor costs for a Health IT developer to meet the proposed requirements in § 170.315(f)(8) for a single product. 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 the tables below.</P>
                    <P>
                        2. According to the May 2022 BLS occupational employment statistics, the mean hourly wage for a “Software Developer” is $63.91.
                        <SU>376</SU>
                        <FTREF/>
                         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 $127.82.
                    </P>
                    <FTNT>
                        <P>
                            <SU>376</SU>
                             
                            <E T="03">https://www.bls.gov/oes/current/oes151252.htm</E>
                            .
                        </P>
                    </FTNT>
                    <GPH SPAN="3" DEEP="285">
                        <PRTPAGE P="63712"/>
                        <GID>EP05AU24.043</GID>
                    </GPH>
                    <GPH SPAN="3" DEEP="107">
                        <GID>EP05AU24.044</GID>
                    </GPH>
                    <P>The cost to a health IT developer to meet the proposed requirements in § 170.315(f)(8) would range from $127,820 to $255,640 per product, on average. 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>
                        The proposed updates are expected to have a wide range of benefits for end-users of health IT. Currently, health care providers rely on manual and duplicative data entry processes to report live births into State vital records programs. With most U.S. births occur at birthing facilities or in hospital settings, birth reporting typically entails clinicians supplying the medical and health information for the birth certificate to a State web-based Electronic Birth Registration System (EBRS). Typically, non-clinical hospital staff collect the legal and demographic information from the mother through a standardized worksheet, which is then entered into the State EBRS by hospital staff. This information is then sent to the State and a birth certificate is then issued by the State vital records authority. Most of the data necessary to report a live birth is also dually entered into EHRs by providers. As a result, birth reporting processes are duplicative and burdensome for providers and hospital systems. Adopting a standards-based approach to birth reporting would facilitate interoperability between the various systems involved in birth reporting, eliminate duplication of effort associated with entering information into multiple systems, and reduce burden of reporting for providers and hospital systems. Standards-based exchange would also improve the timeliness, accuracy, and completeness of birth reporting data.
                        <E T="51">377 378</E>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>377</SU>
                             Standards for Vital Records (
                            <E T="03">cdc.gov</E>
                            ).
                        </P>
                        <P>
                            <SU>378</SU>
                             MN Readiness Assessment Addendum Report September 2015 (
                            <E T="03">cdc.gov</E>
                            ).
                        </P>
                    </FTNT>
                    <P>
                        While there has been very little uptake of the FHIR standard and associated functionalities by health IT vendors,
                        <SU>379</SU>
                        <FTREF/>
                         a pilot study of four Michigan hospitals and their EHRs found increased data completion and accuracy for many data items when births were reported using the FHIR standard and a SMART-on-FHIR app when compared to reports completed manually by hospital staff.
                        <SU>380</SU>
                        <FTREF/>
                         This early evidence suggests the standard, when adopted broadly, could aid in timely, more complete and accurate reporting from hospitals with reduced burden on the reporting facilities. While we recognize the burden associated with 
                        <PRTPAGE P="63713"/>
                        switching from largely manual processes to electronic, standards-based reporting, we expect significant cost savings from reduced manual data entry into multiple systems to surpass the one-time costs associated with implementation.
                    </P>
                    <FTNT>
                        <P>
                            <SU>379</SU>
                             Subsection II-R New Interop Need Table_HIMSS.pdf (
                            <E T="03">healthit.gov</E>
                            ).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>380</SU>
                             Final Report submitted to Centers for Disease Control and Prevention In response to Request for Task Order Proposal No. (MI 2020-Q-45799), June 16, 2023.
                        </P>
                    </FTNT>
                    <P>While the benefits of this proposal are not quantifiable at this time, we expect the proposed requirements to significantly benefit end users of health IT. Specifically, adopting a standards-based approach to birth reporting would enable consistent capture of critical data elements, facilitate public health data interoperability between health care and public health, and reduce reporting burden for health care providers.</P>
                    <HD SOURCE="HD3">§ 170.315(f)(9) Prescription Drug Monitoring Program (PDMP) Databases—Query, Receive, Validate, Parse, and Filter</HD>
                    <P>We propose to create a new certification criterion in § 170.315(f)(9) Prescription Drug Monitoring Program (PDMP) Data—Query, receive, validate, parse and filter to enable the bidirectional interaction and electronic data exchange between health IT and PDMPs. We propose a new functional certification criterion in § 170.315(f)(9) that would be agnostic to a specific PDMP standard, but would include transport, content, and vocabulary standards where appropriate. We propose to additionally include functional requirements for access controls including access roles and audit logs within this new certification criterion. This certification criterion would enable a user to query a PDMP, including bidirectional interstate exchange, to receive PDMP data in an interoperable manner, to establish access roles in accordance with applicable law, and to maintain records of access and auditable events.</P>
                    <HD SOURCE="HD3">Costs</HD>
                    <P>This section describes the estimated costs of meeting the proposed requirements in § 170.315(f)(9). Since this new certification criterion is not currently tied to any requirements, we estimate the costs for a single developer to voluntarily certify but do not assess industry wide costs associated with adoption. Thus, we estimate the number of labor hours that would be needed from a Health IT developer to perform each part of the proposed requirements for a given product. The level of effort associated with meeting requirements for a single product is detailed in Table 47 below and is based on the following assumptions:</P>
                    <P>1. Health IT developers will use the same labor costs and data models. Table 40 shows the estimated labor costs for a Health IT developer to meet the proposed requirements in § 170.315(f)(9) for a single product. 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 the tables below.</P>
                    <P>
                        2. According to the May 2022 BLS occupational employment statistics, the mean hourly wage for a “Software Developer” is $63.91.
                        <SU>381</SU>
                        <FTREF/>
                         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 $127.82.
                    </P>
                    <FTNT>
                        <P>
                            <SU>381</SU>
                             
                            <E T="03">https://www.bls.gov/oes/current/oes151252.htm</E>
                            .
                        </P>
                    </FTNT>
                    <BILCOD>BILLING CODE 4150-45-P</BILCOD>
                    <GPH SPAN="3" DEEP="640">
                        <PRTPAGE P="63714"/>
                        <GID>EP05AU24.045</GID>
                    </GPH>
                    <GPH SPAN="3" DEEP="278">
                        <PRTPAGE P="63715"/>
                        <GID>EP05AU24.046</GID>
                    </GPH>
                    <GPH SPAN="3" DEEP="177">
                        <GID>EP05AU24.047</GID>
                    </GPH>
                    <BILCOD>BILLING CODE 4150-45-C</BILCOD>
                    <P>The cost to a health IT developer to meet the proposed requirements in § 170.315(f)(9) would range from $0 to $383,460 per product, on average. 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>
                        The proposed updates have a wide range of expected benefits for end-users of health IT (such as physicians, pharmacists, public health practitioners) and the patient populations they serve. PDMPs are useful tools to help inform decision-making at the point of care and promote safe prescribing practices.
                        <SU>382</SU>
                        <FTREF/>
                         However, PDMPs are only useful if providers check the PDMP prior to prescribing controlled substances. Therefore, recent efforts, such as mandated use of PDMPs for prescribers and integrating PDMPs into EHRs,
                        <E T="51">383 384 385</E>
                        <FTREF/>
                         have focused on increasing the frequency of PDMP use and the usability of information contained in them by ensuring that PDMP data are easily accessible in clinical workflows and across State lines.
                        <E T="51">386 387</E>
                        <FTREF/>
                         Early evidence suggests efforts to make PDMPs easier to access and use can aid prescribers in making informed clinical decisions and lead to reductions in controlled substance prescriptions for patients.
                        <SU>388</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>382</SU>
                             Prescription Drug Monitoring Programs (PDMPs) | Healthcare Professionals | Opioids | CDC.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>383</SU>
                             
                            <E T="03">TAG_Mandatory_Enrollment_Use_20200710.pdf</E>
                             (
                            <E T="03">pdmpassist.org</E>
                            ).
                        </P>
                        <P>
                            <SU>384</SU>
                             Prescription Drug Monitoring Programs (PDMPs) | Drug Overdose | CDC Injury Center.
                        </P>
                        <P>
                            <SU>385</SU>
                             Integrating &amp; Expanding Prescription Drug Monitoring Program Data: Lessons from Nine States (
                            <E T="03">cdc.gov</E>
                            ).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>386</SU>
                             Leveraging Prescription Drug Monitoring Program (PDMP) Data in Overdose Prevention and Response (
                            <E T="03">cdc.gov</E>
                            ).
                        </P>
                        <P>
                            <SU>387</SU>
                             Physicians have Widespread Access to State PDMP Data, but Data Sharing Varies Across States—Health IT Buzz Health IT Buzz.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>388</SU>
                             National Estimates and Physician-Reported Impacts of Prescription Drug Monitoring Program Use | SpringerLink.
                        </P>
                    </FTNT>
                    <PRTPAGE P="63716"/>
                    <P>
                        While requirements and incentives are in place for providers to access PDMPs, there are no known requirements regarding the capability for health IT to query PDMPs directly, creating a gap in interoperability. There are also no requirements for integrating query information into clinical workflows within health IT systems. These functionalities are critical components to ensuring PDMP data interoperability as State mandates for prescribers to query the PDMP cannot be effective if the technology is not there to support this requirement. A recent study found that the uptick in PDMP use following the adoption of a State mandate requiring clinicians to query the PDMP before prescribing opioids was considerably smaller than the changes resulting from an EHR-integrated PDMP tool making PDMP data easier to access and use.
                        <SU>389</SU>
                        <FTREF/>
                         Inclusion of a functional certification criterion to support PDMP data exchange will help ensure that health IT has the functional capabilities required to engage with a PDMP meeting the definitions under Section 5042(a) of the SUPPORT Act.
                        <SU>390</SU>
                        <FTREF/>
                         These capabilities include enabling health IT systems to support integration of query into clinical workflows informed by established CDC guidelines for opioid prescribing and to support requirements for the capability to reconcile queried data as discrete data elements (not just as read only). Implementing these functionalities would promote interoperability between health IT and PDMPs and increase providers' access to PDMP data at the point of care.
                    </P>
                    <FTNT>
                        <P>
                            <SU>389</SU>
                             Prescription Drug Monitoring Program Mandates: Impact On Opioid Prescribing And Related Hospital Use—PMC (
                            <E T="03">nih.gov</E>
                            ).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>390</SU>
                             Report to Congress: State Challenges and Best Practices Implementing PDMP Requirements Under Section 5042 of the SUPPORT Act (
                            <E T="03">medicaid.gov</E>
                            ).
                        </P>
                    </FTNT>
                    <P>
                        There is substantial evidence to suggest that integrating query information into clinical workflows within health IT systems would help reduce clinical burden and increase the likelihood that authorized users check the PDMP,
                        <SU>391</SU>
                        <FTREF/>
                         as PDMP-EHR integration has been shown to be associated with greater frequency and ease of PDMP use.
                        <E T="51">392 393 394 395 396 397</E>
                        <FTREF/>
                         A 2020 GAO analysis of interviews with physicians and PDMP officials estimated that checking a PDMP database integrated into the EHR takes 2-15 seconds, compared with 3-5 minutes for checking a PDMP database not integrated into the EHR.
                        <SU>398</SU>
                        <FTREF/>
                         The same GAO report noted that PDMPs not integrated into the EHR required more than a dozen additional mouse clicks, representing significant time savings for authorized users to check the PDMP.
                        <SU>399</SU>
                        <FTREF/>
                         PDMP-EHR integration is widely recognized as a strategy for improving the utility of PDMPs in inpatient and outpatient settings. A 2016 expert panel to define best practices for PDMPs in the emergency department setting recommended that prescription drug monitoring program data should be pushed into hospital EHRs.
                        <SU>400</SU>
                        <FTREF/>
                         Recent surveys and semi-structured interviews also found that PDMP-EHR integration was preferred by multi-disciplinary health care providers, who felt that improving the interface and function of the PDMP through integration would increase PDMP use.
                        <E T="51">401 402</E>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>391</SU>
                             Leveraging Prescription Drug Monitoring Programs and Health Information Technology for Addressing Substance Use Disorder and Opioid Use Disorder (LPASO) (
                            <E T="03">healthit.gov</E>
                            ).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>392</SU>
                             National Estimates and Physician-Reported Impacts of Prescription Drug Monitoring Program Use—PubMed (
                            <E T="03">nih.gov</E>
                            ).
                        </P>
                        <P>
                            <SU>393</SU>
                             The Impact of a PDMP-EHR Data Integration combined with Clinical Decision Support on Opioid and Benzodiazepine Prescribing Across Clinicians in a Metropolitan Area—PMC (
                            <E T="03">nih.gov</E>
                            ).
                        </P>
                        <P>
                            <SU>394</SU>
                             Provider perspectives and experiences following the integration of the prescription drug monitoring program into the electronic health record—Matthew Witry, Barbara St Marie, Jeffrey Reist, 2022 (
                            <E T="03">sagepub.com</E>
                            ).
                        </P>
                        <P>
                            <SU>395</SU>
                             Effect of Integrating Access to a Prescription Drug Monitoring Program Within the Electronic Health Record on the Frequency of Queries by Primary Care Clinicians: A Cluster Randomized Clinical Trial—PubMed (
                            <E T="03">nih.gov</E>
                            ).
                        </P>
                        <P>
                            <SU>396</SU>
                             Barriers and facilitators to PDMP IS Success in the US: A systematic review—PubMed (
                            <E T="03">nih.gov</E>
                            )/.
                        </P>
                        <P>
                            <SU>397</SU>
                             Provider beliefs on the Barriers and Facilitators to Prescription Monitoring Programs and Mandated Use—PubMed (
                            <E T="03">nih.gov</E>
                            ).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>398</SU>
                             Prescription Drug Monitoring Programs: Views on Usefulness and Challenges of Programs | U.S. GAO.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>399</SU>
                             Ibid.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>400</SU>
                             Best Practices for Prescription Drug Monitoring Programs in the Emergency Department Setting: Results of an Expert Panel—PubMed (
                            <E T="03">nih.gov</E>
                            ).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>401</SU>
                             Barriers to Increasing Prescription Drug Monitoring Program . . . : CIN: Computers, Informatics, Nursing (
                            <E T="03">lww.com</E>
                            ).
                        </P>
                        <P>
                            <SU>402</SU>
                             Provider beliefs on the Barriers and Facilitators to Prescription Monitoring Programs and Mandated Use—PubMed (
                            <E T="03">nih.gov</E>
                            ).
                        </P>
                    </FTNT>
                    <P>
                        In addition to providing benefits to end users of health IT, including prescribers and pharmacists, these requirements would benefit patient populations by increasing the provision of guideline-concordant care, such as checking the PDMP before prescribing opioids to confirm the appropriateness of treatment. One systematic review found that PDMP use influences health care providers' clinical decision-making in relation to the supply of controlled substances, refusal to prescribe or treat, risk mitigation strategies, communication, education and counselling, referrals and care coordination, and stigma.
                        <SU>403</SU>
                        <FTREF/>
                         PDMP use has also been shown to be associated with several benefits including reductions in opioid prescribing rates, opioid-related inpatient stays, and opioid-related emergency department visits as well as better care coordination for patients and informed clinical decision-making.
                        <E T="51">404 405 406</E>
                        <FTREF/>
                         PDMP supports which allow for integration and the interoperability of PDMP data can support advancement of patient-centered care that focuses on the specific needs, and safety, of the individual. For example, the viewing of opioid therapies and nonopioid therapies together supports the 2022 CDC Clinical Practice Guideline for Prescribing Opioids, Recommendation 1: “Nonopioid therapies are at least as effective as opioids for many common types of acute pain. Clinicians should maximize use of nonpharmacologic and nonopioid pharmacologic therapies as appropriate for the specific condition and patient and only consider opioid therapy for acute pain if benefits are anticipated to outweigh risks to the patient. Before prescribing opioid therapy for acute pain, clinicians should discuss with patients the realistic benefits and known risks of opioid therapy.” 
                        <SU>407</SU>
                        <FTREF/>
                         The CDC recommends that PDMP data should be reviewed before every opioid prescription for acute, subacute, or chronic pain. Universal application of PDMP queries would mitigate bias and therefore the recommendation is that clinicians should query the PDMP when feasible for all patients rather than differentially based on assumptions about what they will learn about specific patients. EHR integration of PDMP data would increase feasibility of universal application.
                    </P>
                    <FTNT>
                        <P>
                            <SU>403</SU>
                             How prescription drug monitoring programs influence clinical decision-making: A mixed methods systematic review and meta-analysis—ScienceDirect.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>404</SU>
                             Prescription Drug Monitoring Program Mandates: Impact On Opioid Prescribing And Related Hospital Use—PMC (
                            <E T="03">nih.gov</E>
                            ).
                        </P>
                        <P>
                            <SU>405</SU>
                             Integrating &amp; Expanding Prescription Drug Monitoring Program Data: Lessons from Nine States (
                            <E T="03">cdc.gov</E>
                            ).
                        </P>
                        <P>
                            <SU>406</SU>
                             National Estimates and Physician-Reported Impacts of Prescription Drug Monitoring Program Use—PubMed (
                            <E T="03">nih.gov</E>
                            ).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>407</SU>
                             CDC's Clinical Practice Guideline for Prescribing Opioids for Pain | Guidelines | Healthcare Professionals | Opioids | CDC.
                        </P>
                    </FTNT>
                    <P>
                        While the benefits of many of these modifications are not quantifiable at this time, we expect the resulting improvements to significantly improve data interoperability between health IT systems and PDMPs, which will reduce burden on providers to access the PDMP and improve their access to information 
                        <PRTPAGE P="63717"/>
                        needed for clinical decision-making. Reductions in clicks needed to access the PDMP translates to reductions in time in takes staff to access and review PDMP data, which could result in significant time and cost savings for prescribers to access and use PDMP data. Timely access to PDMP data can help improve care coordination for individual patients, but it can also be an important tool for public health surveillance by enabling health departments to identify at-risk communities and provide targeted outreach and intervention.
                        <SU>408</SU>
                        <FTREF/>
                         We expect these improvements to benefit both individual patients and communities by enabling prescribers to make informed treatment decisions and equipping public health agencies with the information needed to develop initiatives for safe and appropriate prescribing, prevention and treatment of substance use disorders, and risk-reduction for opioid overdose.
                        <SU>409</SU>
                    </P>
                    <FTNT>
                        <P>
                            <SU>408</SU>
                             In Brief, Prescription Drug Monitoring Programs: A Guide for Healthcare Providers (
                            <E T="03">samhsa.gov</E>
                            ).
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">b. Proposed New Certification Criteria for Health IT Modules Supporting Public Health Data Exchange in § 170.315(f)</HD>
                    <HD SOURCE="HD3">§ 170.315(f)(21) Immunization Information—Receive, Validate, Parse, Filter, and Exchange—Response</HD>
                    <P>We propose a new certification criterion for immunization information receipt, validation, parsing, and filtering, as well as exchange and response as a complement to the proposed updated requirements in § 170.315(f)(1). We propose requirements in § 170.315(f)(21) to enable a system to receive, validate, parse, and filter electronic immunization information in accordance with the standard and applicable implementation guide specified in § 170.205(e). We also propose a new functional exchange requirement for the capability to respond to incoming patient-level and/or immunization-specific queries from external systems.</P>
                    <HD SOURCE="HD3">Costs</HD>
                    <P>This section describes the estimated costs for an Immunization information system (IIS) vendor to meet the proposed requirements in § 170.315(f)(21). Since this certification criterion is not currently tied to any requirements, we estimate the costs for a single developer to voluntarily certify but do not assess industry wide costs associated with adoption. While it is common for jurisdictions to customize their IIS to meet their unique needs, here we assess the costs associated with updating the base functionality of an IIS to meet the above requirements. Thus, we estimate the number of labor hours that would be needed from an IIS vendor to perform each part of the proposed requirements for a given system. Each task is assumed to have its own level of effort, and these estimates are detailed in Table 49 below and are based on the following assumptions:</P>
                    <P>1. IIS vendors will use the same labor costs and data models. Table 42 shows the estimated labor costs for a vendor to meet the proposed requirements in § 170.315(f)(21) for a single system. We recognize that vendor costs will vary; however, our estimates in this section assume all IIS vendors will incur the costs noted in the tables below.</P>
                    <P>
                        2. According to the May 2022 BLS occupational employment statistics, the mean hourly wage for a “Software Developer” is $63.91.
                        <SU>410</SU>
                        <FTREF/>
                         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 $127.82.
                    </P>
                    <FTNT>
                        <P>
                            <SU>410</SU>
                             
                            <E T="03">https://www.bls.gov/oes/current/oes151252.htm.</E>
                        </P>
                    </FTNT>
                    <GPH SPAN="3" DEEP="415">
                        <PRTPAGE P="63718"/>
                        <GID>EP05AU24.048</GID>
                    </GPH>
                    <GPH SPAN="3" DEEP="138">
                        <GID>EP05AU24.049</GID>
                    </GPH>
                    <P>The cost to an IIS vendor to meet the proposed requirements in § 170.315(f)(21) would range from $0 to $255,640 per system, on average. This would be a one-time cost to developers per system that is certified to the specified certification criterion and would not be perpetual.</P>
                    <HD SOURCE="HD3">Benefits</HD>
                    <P>
                        The proposed requirements for Health IT Modules supporting public health data exchange would benefit public health agencies (PHAs) who rely on timely, actionable data from healthcare partners. While the benefits associated with this proposal are not quantifiable at this time, we expect adoption of these new functional requirements in (f)(21) to improve bidirectional interoperability between healthcare and public health. By including functions performed by public health facing technology within the certification criterion, foundational capabilities will be in place by receiving 
                        <PRTPAGE P="63719"/>
                        technology for bidirectional data exchange, completing a critical component of the immunization exchange workflow.
                    </P>
                    <P>Functionality for receipt, validation, transmission, query/response, and patient access will enable more users, including those using a variety of health IT systems, to have the most complete and accurate vaccine history for individuals. This functionality can help advance EHRs, IISs, and intermediaries in alignment, with the same foundational functionalities, and that data are moving with the speed of care. If an individual receives a vaccine from a pharmacy, from a community health clinic, away from their home State, or at their provider's office, any approved user, regardless of their health IT system, should be able to have access to their complete, accurate vaccine history. Further, it aligns the technology used by public health officials and immunization programs with the same standard that providers and health care organizations are required to use for transmission, without additional manual effort or manipulation. We believe these proposed requirements, coupled with proposed (g)(20) and updates to (f)(1), can move the nation closer to this ideal state.</P>
                    <HD SOURCE="HD3">§ 170.315(f)(22) Syndromic Surveillance—Receive, Validate, Parse, and Filter</HD>
                    <P>We propose a new certification criterion for the functional requirement to receive, validate, parse, and filter incoming syndromic surveillance information in accordance with the standard and applicable implementation guide specified in § 170.205(d). The transmission of information electronically must be accompanied by the ability for public health technology to receive and validate information according to the same standard and use these standardized data for analysis and to inform next steps. Receipt and validation functions are needed to reduce the need for manual effort or manipulation related to data integration and processing, and to allow for the prompt intake and analysis of information.</P>
                    <HD SOURCE="HD3">Costs</HD>
                    <P>This section describes the estimated costs for a syndromic surveillance system vendor to meet the proposed requirements in § 170.315(f)(22). Since this certification criterion is not currently tied to any requirements, we estimate the costs for a single vendor to voluntarily certify but do not assess industry wide costs associated with adoption. While jurisdictions may customize their systems to meet their unique needs, here we assess the costs associated with updating the base functionality of surveillance systems to meet the above requirements. Thus, we estimate the number of labor hours that would be needed from surveillance system vendors to perform each part of the proposed requirements for a given system. Each task is assumed to have its own level of effort, and these estimates are detailed in Table 51 below and are based on the following assumptions:</P>
                    <P>1. Syndromic surveillance system vendors will use the same labor costs and data models. Table 44 shows the estimated labor costs for a developer to meet the proposed requirements in § 170.315(f)(22) for a single system. We recognize that vendor costs will vary; however, our estimates in this section assume all vendors will incur the costs noted in the tables below.</P>
                    <P>
                        2. According to the May 2022 BLS occupational employment statistics, the mean hourly wage for a “Software Developer” is $63.91.
                        <SU>411</SU>
                        <FTREF/>
                         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 $127.82.
                    </P>
                    <FTNT>
                        <P>
                            <SU>411</SU>
                             
                            <E T="03">https://www.bls.gov/oes/current/oes151252.htm.</E>
                        </P>
                    </FTNT>
                    <GPH SPAN="3" DEEP="257">
                        <GID>EP05AU24.050</GID>
                    </GPH>
                    <GPH SPAN="3" DEEP="123">
                        <PRTPAGE P="63720"/>
                        <GID>EP05AU24.051</GID>
                    </GPH>
                    <P>The cost to a vendor to meet the proposed requirements in § 170.315(f)(22) would range from $0 to $95,865 per system, on average. This would be a one-time cost to developers per system that is certified to the specified certification criterion and would not be perpetual.</P>
                    <HD SOURCE="HD3">Benefits</HD>
                    <P>The proposed requirements for Health IT Modules supporting public health data exchange would benefit public health agencies (PHAs) who rely on timely, actionable data from healthcare partners and promote public health data interoperability. Syndromic surveillance information is vital to the monitoring and early detection of potential public health events and can help provide PHAs with the information needed to prevent a threat from becoming a public health emergency. The transmission of information electronically, according to the standard specified in § 170.205(d), must be accompanied by the ability for public health systems to receive and validate information according to the same standard, and use the standardized data for analysis and to inform next steps. Receipt and validation functions would benefit public health agencies by reducing the need for manual effort or manipulation related to data integration and processing and allowing for prompt intake and analysis of information. The pandemic raised the importance of certain data elements being included in the standard to better assess hot spots and inform response, including travel status, pregnancy status, acuity, and admission information—all of which are reflected in the updated version of the standard specified in § 170.205(d).</P>
                    <P>While the benefits of adopting this new functional requirement are not quantifiable at this time, we expect the resulting improvements to help reduce the time needed to onboard new data sources and make syndromic surveillance able to scale and respond to new public health threats as well as meet daily operational needs. Additionally, it would create a foundational functionality requirement for all syndromic surveillance systems to be able to validate and assess incoming information quickly to identify emerging threats. While receipt is a function that most syndromic surveillance systems can accomplish today, our proposal to certify this functionality would allow for several additional benefits. First, it would include both sending and receiving systems in testing the shared standard, finding issues, and aligning on how to constrain specifications to limit variability. Second, it would advance syndromic surveillance technology on the same path as the systems reporting data to them, to allow all involved systems to grow and align in concert when it comes to data exchange—eliminating the need for manual workarounds or costly third parties to fill the gaps between functionalities. Third, the coordination between sending and receiving systems would compel nationwide upgrades and transitions as needs and use cases evolve and shift.</P>
                    <HD SOURCE="HD3">§ 170.315(f)(23) Reportable Laboratory Test Values/Results—Receive, Validate, Parse, and Filter</HD>
                    <P>We propose a new requirement in § 170.315(f)(23) to enable technology to receive, validate, parse, and filter incoming laboratory tests and results/values according to the standard in § 170.205(g)(3), the HL7® Laboratory Results Interface (LRI) Implementation Guide, or the ELR IG. By requiring Health IT Modules supporting public health data exchange to receive results and values electronically (according to national standards), more complete patient information will be available to clinicians throughout the laboratory workflow and for public health action.</P>
                    <HD SOURCE="HD3">Costs</HD>
                    <P>This section describes the estimated costs for a system vendor to meet the proposed requirements in § 170.315(f)(23). Since this certification criterion is not currently tied to any requirements, we estimate the costs for a single vendor to voluntarily certify but do not assess industry wide costs associated with adoption. While jurisdictions may customize their systems to meet their unique needs, here we assess the costs associated with updating the base functionality of systems to meet the above requirements. Thus, we estimate the number of labor hours that would be needed from vendors to perform each part of the proposed requirements for a given system. Each task is assumed to have its own level of effort, and these estimates are detailed in Table 53 below and are based on the following assumptions:</P>
                    <P>1. Vendors will use the same labor costs and data models. Table 46 shows the estimated labor costs for a developer to meet the proposed requirements in § 170.315(f)(23) for a single system. We recognize that vendor costs will vary; however, our estimates in this section assume all vendors will incur the costs noted in the tables below.</P>
                    <P>
                        2. According to the May 2022 BLS occupational employment statistics, the mean hourly wage for a “Software Developer” is $63.91.
                        <SU>412</SU>
                        <FTREF/>
                         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 $127.82.
                    </P>
                    <FTNT>
                        <P>
                            <SU>412</SU>
                             
                            <E T="03">https://www.bls.gov/oes/current/oes151252.htm.</E>
                        </P>
                    </FTNT>
                    <GPH SPAN="3" DEEP="285">
                        <PRTPAGE P="63721"/>
                        <GID>EP05AU24.052</GID>
                    </GPH>
                    <GPH SPAN="3" DEEP="122">
                        <GID>EP05AU24.053</GID>
                    </GPH>
                    <P>The cost to a vendor to meet the proposed requirements in § 170.315(f)(23) would range from $63,910 to $319,550 per system, on average. This would be a one-time cost to developers per system that is certified to the specified certification criterion and would not be perpetual.</P>
                    <HD SOURCE="HD3">Benefits</HD>
                    <P>The proposed requirements for Health IT Modules supporting public health data exchange would benefit public health agencies (PHAs) who rely on timely, actionable data from healthcare partners and laboratories. The proposed requirements would help increase the data shared between health care providers, laboratories, and public health agencies, and would increase interoperability among the different systems in place at each entity. To encompass all aspects of the laboratory workflow, the proposed requirements in § 170.315(f)(23) for public health data systems to receive results and values electronically according to the LRI IG align with the proposed requirements in § 170.315(a)(2) for a user to create and transmit laboratory orders electronically according to the HL7® Laboratory Order Interface (LOI) Implementation Guide and the proposed requirements in § 170.315(f)(3) for Health IT Modules to create and transmit laboratory orders according to the LOI IG and receive laboratory results according to the LRI IG.</P>
                    <P>Together, these proposals will help ensure that laboratory results and orders are sent and received according to the same standards and that all systems involved in the workflow have the same baseline functionality.</P>
                    <P>While the benefits of this proposal are not quantifiable at this time, the proposed requirements would help ensure that public health agencies are able to receive electronically transmitted laboratory values/results in their system(s) in a standardized format, resulting in more complete patient information being available for public health action. We expect adoption of the LRI IG, in particular, to enable providers and laboratories to send more complete data to public health agencies that are needed to inform rapid response and assist with contact tracing and patient outreach during outbreaks of infectious disease.</P>
                    <HD SOURCE="HD3">§ 170.315(f)(24) Cancer Pathology Reporting—Receive, Validate, Parse, and Filter</HD>
                    <P>
                        We propose a new certification criterion for receiving and validating incoming cancer pathology reports according to the proposed standard in 
                        <PRTPAGE P="63722"/>
                        § 170.205(i)(4), Cancer Pathology Data Sharing 1.0.0—STU1. In order for cancer registries to receive, validate, parse and filter these reports according to the standard proposed in § 170.315(f)(4), we propose to include an accompanying requirement for the receipt, validation, parsing, and filtering of cancer pathology reports in § 170.315(f)(24).
                    </P>
                    <HD SOURCE="HD3">Costs</HD>
                    <P>This section describes the estimated costs for a cancer registry vendor to meet the proposed requirements in § 170.315(f)(24). Since this certification criterion is not currently tied to any requirements, we estimate the costs for a single vendor to voluntarily certify but do not assess industry wide costs associated with adoption. While jurisdictions may customize their registries to meet their unique needs, here we assess the costs associated with updating the base functionality of systems to meet the above requirements. Thus, we estimate the number of labor hours that would be needed from cancer registry vendors to perform each part of the proposed requirements for a given system. Each task is assumed to have its own level of effort, and these estimates are detailed in Table 55 below and are based on the following assumptions:</P>
                    <P>1. Cancer registry vendors will use the same labor costs and data models. Table 48 shows the estimated labor costs for a vendor to meet the proposed requirements in § 170.315(f)(24) for a single system. We recognize that vendor costs will vary; however, our estimates in this section assume all vendors will incur the costs noted in the tables below.</P>
                    <P>
                        2. According to the May 2022 BLS occupational employment statistics, the mean hourly wage for a “Software Developer” is $63.91.
                        <SU>413</SU>
                        <FTREF/>
                         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 $127.82.
                    </P>
                    <FTNT>
                        <P>
                            <SU>413</SU>
                             
                            <E T="03">https://www.bls.gov/oes/current/oes151252.htm.</E>
                        </P>
                    </FTNT>
                    <GPH SPAN="3" DEEP="257">
                        <GID>EP05AU24.054</GID>
                    </GPH>
                    <GPH SPAN="3" DEEP="122">
                        <GID>EP05AU24.055</GID>
                    </GPH>
                    <P>The cost to a vendor to meet the proposed requirements in § 170.315(f)(24) would range from $0 to $127,820 per system, on average. This would be a one-time cost to developers per system that is certified to the specified certification criterion and would not be perpetual.</P>
                    <HD SOURCE="HD3">Benefits</HD>
                    <P>
                        The proposed requirements for Health IT Modules supporting public health 
                        <PRTPAGE P="63723"/>
                        data exchange would benefit public health agencies (PHAs) who rely on timely, actionable data from healthcare partners and promote public health data interoperability. This proposal would support cancer registries in having the functionality to accept information in the same standard as sending systems, as well as help sending and receiving technology progress at the same rate, with aligned functionality.
                    </P>
                    <P>
                        CDC's National Program of Cancer Registries has been actively working with State public health agencies and pathology partners, including the College of American Pathologists (CAP), to develop and pilot the FHIR Implementation Guide for cancer pathology reporting. Early results of these pilots demonstrate that use of FHIR by all involved systems will reduce the need for manual intervention and data cleansing, aid in more timely reporting, and include more complete information, including the demographic information needed to confirm reporting is happening within the patient's State of residence, rather than the State of treatment, as well as for patient matching.
                        <E T="51">414 415 416</E>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>414</SU>
                             Pursuing Data Modernization in Cancer Surveillance by Developing a Cloud-Based Computing Platform: Real-Time Cancer Case Collection | JCO Clinical Cancer Informatics (
                            <E T="03">ascopubs.org</E>
                            ).
                        </P>
                        <P>
                            <SU>415</SU>
                             Using informatics to improve cancer surveillance—PMC (
                            <E T="03">nih.gov</E>
                            ).
                        </P>
                        <P>
                            <SU>416</SU>
                             The Fast Health Interoperability Resources (FHIR) Standard: Systematic Literature Review of Implementations, Applications, Challenges and Opportunities—PubMed (
                            <E T="03">nih.gov</E>
                            ).
                        </P>
                    </FTNT>
                    <P>While the benefits of this proposal are not quantifiable at this time, we expect the inclusion of receipt, validation, parsing, and filtering of electronic cancer pathology reporting in the Program to result in more complete, accurate diagnostic information being received by State cancer registries. Not only would our proposal support cancer registries in having the functionality to accept information in the same standard as sending systems, but it would help sending and receiving technology progress at the same rate, with aligned functionality. The proposed requirements would also enable cancer registries to receive pathology reports in a structured format rather than narrative form, which would help facilitate use of these data for research, analysis, and intervention.</P>
                    <HD SOURCE="HD3">§ 170.315(f)(25) Electronic Case Reporting—Receive, Validate, Parse, and Filter Electronic Initial Case Reports and Reportability Response; and Create and Transmit Reportability Response</HD>
                    <P>In the HTI-2, we propose requirements in § 170.315(f)(5) for compliance with the HL7 eCR FHIR IG for electronic case reporting from hospitals and providers to public health agencies. We propose a corresponding requirement in § 170.315(f)(25) for technology in place at public health agencies to receive, validate, parse, and filter electronic case reports as well as create and electronically transmit a reportability response (RR) according to the standards referenced in § 170.205(t)(3). This requirement would help advance the technology that receives reported data in alignment with the technology that transmits the reports, adhering to the same foundational functions and standards.</P>
                    <HD SOURCE="HD3">Costs</HD>
                    <P>This section describes the estimated costs for a case surveillance system vendor to meet the proposed requirements in § 170.315(f)(25). Since this certification criterion is not currently tied to any requirements, we estimate the costs for a single developer to voluntarily certify but do not assess industry wide costs associated with adoption. While jurisdictions may customize their systems to meet their unique needs, here we assess the costs associated with updating the base functionality of systems to meet the above requirements. Thus, we estimate the number of labor hours that would be needed from system vendors to perform each part of the proposed requirements for a given system. Each task is assumed to have its own level of effort, and these estimates are detailed in Table 57 below and are based on the following assumptions:</P>
                    <P>1. System vendors will use the same labor costs and data models. Table 50 shows the estimated labor costs for a developer to meet the proposed requirements in § 170.315(f)(25) for a single system. We recognize that vendor costs will vary; however, our estimates in this section assume all vendors will incur the costs noted in the tables below.</P>
                    <P>
                        2. According to the May 2022 BLS occupational employment statistics, the mean hourly wage for a “Software Developer” is $63.91.
                        <SU>417</SU>
                        <FTREF/>
                         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 $127.82.
                    </P>
                    <FTNT>
                        <P>
                            <SU>417</SU>
                             
                            <E T="03">https://www.bls.gov/oes/current/oes151252.htm</E>
                            .
                        </P>
                    </FTNT>
                    <GPH SPAN="3" DEEP="452">
                        <PRTPAGE P="63724"/>
                        <GID>EP05AU24.056</GID>
                    </GPH>
                    <GPH SPAN="3" DEEP="138">
                        <GID>EP05AU24.057</GID>
                    </GPH>
                    <P>The cost to a vendor to meet the proposed requirements in § 170.315(f)(25) would range from $127,820 to $383,460 per system, on average. This would be a one-time cost to developers per system that is certified to the specified certification criterion and would not be perpetual.</P>
                    <HD SOURCE="HD3">Benefits</HD>
                    <P>
                        The proposed requirements for Health IT Modules supporting public health data exchange would benefit public 
                        <PRTPAGE P="63725"/>
                        health agencies (PHAs) who rely on timely, actionable data from healthcare partners and promote public health data interoperability. While the benefits of adopting these proposed requirements are not quantifiable at this time, we expect the resulting improvements to reduce burden associated with processing case reports and alleviate the need for manual intervention. Further, these requirements would help advance and align technology that receives reported data with the technology that transmits case reports, adhering to the same foundational functions and standards. Adherence to a single standard, particularly the FHIR IG, will benefit public health agencies by encouraging consistent implementation and promoting greater interoperability compared to referencing multiple standards. Further, the HL7 eCR FHIR IG allows public health agencies to have more control in configuration, including the data elements and frequency of initial case notifications. Upgrading public health facing technology and tools to support APIs and FHIR payload, as included in the HL7 FHIR eCR IG, creates greater flexibility to respond to emergency issues. Improvements in consistent implementation and interoperability would enable PHAs to have an improved picture of where and when disease outbreaks occur. Supporting this alignment allows the industry to advance in harmony and creates a more scalable infrastructure in times of emergency.
                    </P>
                    <P>Aligning requirements for systems sending and receiving electronic case reports was generally supported by commenters to HTI-1, who suggested that systems receiving electronic case reports should also have to certify to capabilities that align with the requirements in § 170.315(f)(5). One 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. The proposed requirements would therefore help to create alignment between senders and receivers of case report data and enable bidirectional communication between health care and public health. Such improvements in public health data interoperability are critical to enabling public health agencies to receive complete and accurate case report information in a timely manner in order to identify and monitor cases of nationally notifiable conditions, respond quickly to outbreaks of infectious disease, and informs programs and interventions aimed at reducing the incidence of disease.</P>
                    <P>
                        While the benefits of this proposal are not quantifiable at this time, we expect adoption of standards-based requirements for electronic case reporting to result in improved consistency of reporting specific data elements to public health, increased efficiency of exchange (
                        <E T="03">e.g.,</E>
                         by facilitating automated reporting), and greater public health data interoperability between health care and public health. Increasing connectivity through standards-based, electronic case reporting can help ensure that more complete, accurate, timely data are available to support public health response.
                        <E T="51">418 419</E>
                        <FTREF/>
                         In turn, more timely detection of health-related conditions or events of public concern can result in rapid intervention and lowered disease transmission.
                        <E T="51">420 421</E>
                        <FTREF/>
                         More thorough reporting can also improve targeted interventions to improve health of vulnerable populations.
                        <SU>422</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>418</SU>
                             digital-bridge-ecr-evaluation-report-12-32019.pdf (aimsplatform.org).
                        </P>
                        <P>
                            <SU>419</SU>
                             Completeness and timeliness of notifiable disease reporting: a comparison of laboratory and provider reports submitted to a large county health department | BMC Medical Informatics and Decision Making | Full Text (
                            <E T="03">biomedcentral.com</E>
                            ).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>420</SU>
                             The Promise of Electronic Case Reporting—PubMed (
                            <E T="03">nih.gov</E>
                            ).
                        </P>
                        <P>
                            <SU>421</SU>
                             Public Health Agencies (
                            <E T="03">aimsplatform.org</E>
                            ).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>422</SU>
                             
                            <E T="03">digital-bridge-ecr-evaluation-report-12-32019.pdf</E>
                             (
                            <E T="03">aimsplatform.org</E>
                            ).
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">§ 170.315(f)(28) Birth Reporting—Receive, Validate, Parse, and Filter</HD>
                    <P>We propose a requirement in § 170.315(f)(28) for the receipt, validation, parsing, and filtering of incoming birth reports according to the FHIR IG for birth reporting in § 170.205(v) and referenced in § 170.315(f)(8) to create alignment between systems sending and receiving birth reports. Inclusion of the FHIR standard in regulation would align the technology receiving birth reports with those sending the reports.</P>
                    <HD SOURCE="HD3">Costs</HD>
                    <P>This section describes the estimated costs for an electronic birth registry system (EBRS) vendor to meet the proposed requirements in § 170.315(f)(28). Since this certification criterion is not currently tied to any requirements, we assess the cost for a single developer to voluntarily certify but do not assess industry wide costs associated with adoption. While jurisdictions may customize their systems to meet their unique needs, here we assess the costs associated with updating the base functionality of EBRS to meet the above requirements. Thus, we estimate the number of labor hours that would be needed from system vendors to perform each part of the proposed requirements for a given system. Each task is assumed to have its own level of effort, and these estimates are detailed in Table 59 below and are based on the following assumptions:</P>
                    <P>1. EBRS vendors will use the same labor costs and data models. Table 52 shows the estimated labor costs for a developer to meet the proposed requirements in § 170.315(f)(25) for a single system. We recognize that vendor costs will vary; however, our estimates in this section assume all vendors will incur the costs noted in the tables below.</P>
                    <P>
                        2. According to the May 2022 BLS occupational employment statistics, the mean hourly wage for a “Software Developer” is $63.91.
                        <SU>423</SU>
                        <FTREF/>
                         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 $127.82.
                    </P>
                    <FTNT>
                        <P>
                            <SU>423</SU>
                             
                            <E T="03">https://www.bls.gov/oes/current/oes151252.htm</E>
                            .
                        </P>
                    </FTNT>
                    <GPH SPAN="3" DEEP="257">
                        <PRTPAGE P="63726"/>
                        <GID>EP05AU24.058</GID>
                    </GPH>
                    <GPH SPAN="3" DEEP="122">
                        <GID>EP05AU24.059</GID>
                    </GPH>
                    <P>The cost to a vendor to meet the proposed requirements in § 170.315(f)(28) would range from $127,820 to $255,640 per system, on average. This would be a one-time cost to developers per system that is certified to the specified certification criterion and would not be perpetual.</P>
                    <HD SOURCE="HD3">Benefits</HD>
                    <P>The proposed requirements for Health IT Modules supporting public health data exchange would benefit public health agencies (PHAs) who rely on timely, actionable data from healthcare partners and promote public health data interoperability. Birth reporting helps inform public health programs, is used for research and surveillance, and is used to produce the birth certificates needed for proof of identification, accessing benefits, and other administrative purposes. However, much of the birth reporting process currently relies on manual data entry and there remains a gap in public health agencies' ability to receive and integrate data within applicable public health technology, particularly for data received used FHIR-based standards.</P>
                    <P>
                        Requiring that technology receiving birth reports can do so according to the standard specified in § 170.315(f)(8) would create alignment between sending and receiving systems. Inclusion of the ability to receive and validate FHIR within applicable public health technology supporting birth reporting will also provide a baseline set of capabilities that public health technology vendors can build on as additional FHIR-based approaches emerge for public health, including Bulk Import of data and FHIR Questionnaires. The receipt of FHIR for birth records also supports investments being made by CDC to receive FHIR messages downstream through the Data Modernization Initiative.
                        <SU>424</SU>
                        <FTREF/>
                         While the benefits of this proposed requirement are not quantifiable at this time, we expect adoption of the FHIR IG for birth reporting to reduce implementation and maintenance burden, and lead to greater consistency and completeness in reported information.
                    </P>
                    <FTNT>
                        <P>
                            <SU>424</SU>
                             
                            <E T="03">https://www.cdc.gov/surveillance/data-modernization/technologies/cdc-front-door.html</E>
                            .
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">§ 170.315(f)(29) Prescription Drug Monitoring Program (PDMP) Databases—Receive, Validate, Filter, and Parse Prescription Data, Support Query and Exchange</HD>
                    <P>
                        We propose to introduce functional certification criteria certifying the ability of Health IT Modules supporting public health use cases to receive and validate reported PDMP information, and to initiate and respond to queries from providers or other PDMP databases and hubs. To complement our proposal in § 170.315(f)(9) to support certification of health IT used by providers to be capable of requesting data from PDMP databases, we also believe it is important to certify the capability of 
                        <PRTPAGE P="63727"/>
                        public health systems, including PDMP technology, to respond to queries submitted. Our proposal will require that functionality is based on open, consensus-based practices where possible, allowing PDMPs to have the ability to exchange information without undue burden. Additionally, PDMPs should have the capability to support interstate data sharing (or queries) to better inform prescribing practices and monitor drug misuse and diversion. ONC proposes a set of functional certification criteria in § 170.315(f)(29) for receiving and validating reported data and initiating and responding to queries from applicable health IT, including other State PDMPs, to support applicable health IT capabilities required under Section 5042(a) of the Support Act.
                    </P>
                    <HD SOURCE="HD3">Costs</HD>
                    <P>This section describes the estimated costs for a PDMP vendor to meet the proposed requirements in § 170.315(f)(29). Since this certification criterion is not currently tied to any requirements, we assess the cost for a single PDMP developer to voluntarily certify but do not assess industry wide costs associated with adoption. While States may customize their systems to meet their unique needs, here we assess the costs associated with updating the base functionality of systems to meet the above requirements. Thus, we estimate the number of labor hours that would be needed from PDMP vendors to perform each part of the proposed requirements for a given system. Each task is assumed to have its own level of effort, and these estimates are detailed in Table 61 below and are based on the following assumptions:</P>
                    <P>1. PDMP vendors will use the same labor costs and data models. Table 54 shows the estimated labor costs for a developer to meet the proposed requirements in § 170.315(f)(25) for a single system. We recognize that vendor costs will vary; however, our estimates in this section assume all vendors will incur the costs noted in the tables below.</P>
                    <P>
                        2. According to the May 2022 BLS occupational employment statistics, the mean hourly wage for a “Software Developer” is $63.91.
                        <SU>425</SU>
                        <FTREF/>
                         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 $127.82.
                    </P>
                    <FTNT>
                        <P>
                            <SU>425</SU>
                             
                            <E T="03">https://www.bls.gov/oes/current/oes151252.htm</E>
                            .
                        </P>
                    </FTNT>
                    <BILCOD>BILLING CODE 4150-45-P</BILCOD>
                    <GPH SPAN="3" DEEP="632">
                        <PRTPAGE P="63728"/>
                        <GID>EP05AU24.060</GID>
                    </GPH>
                    <GPH SPAN="3" DEEP="360">
                        <PRTPAGE P="63729"/>
                        <GID>EP05AU24.061</GID>
                    </GPH>
                    <GPH SPAN="3" DEEP="191">
                        <GID>EP05AU24.062</GID>
                    </GPH>
                    <BILCOD>BILLING CODE 4150-45-C</BILCOD>
                    <P>The cost to a health IT developer to meet the proposed requirements in § 170.315(f)(29) would range from $127,820 to $383,460 per product, on average. 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>
                        The proposed requirements for Health IT Modules supporting the exchange of PDMP data will help ensure that PDMPs can receive and validate reported PDMP information and initiate and respond to queries from providers or other State PDMPs to better inform prescribing practices and monitor drug misuse and diversion. A lack of consistent interoperability requirements between PDMPs and systems involved in interstate exchange makes such queries burdensome on both the querying and responding systems. Inclusion of a certification criterion in the Program will help alleviate this burden by 
                        <PRTPAGE P="63730"/>
                        supporting PDMP capabilities in alignment with requirements for health IT systems to request and validate data from PDMP databases. These new functional requirements for PDMPs will also help States conform to functionalities specified in Section 5042(a) of the SUPPORT Act to support interjurisdictional query and response, and to receive and validate data into health IT.
                    </P>
                    <HD SOURCE="HD3">New Standardized API for Public Health Data Exchange</HD>
                    <P>We propose a new certification criterion in § 170.315(g)(20) that would establish requirements for a standardized FHIR-based API for public health reporting. This new certification criterion would support ongoing and future development of public health FHIR IGs leveraging a core set of existing, generalizable, and extensible capabilities and standards. The new certification criterion would include FHIR capabilities proposed in § 170.315(j), which are proposed elsewhere in this rule. These certification criteria include FHIR capabilities such as FHIR Subscriptions, CDS Hooks, and SMART Health Cards, as well as requirements for authorization and authentication, among others. Our proposals in § 170.315(g)(20) would also include customized requirements for public health such as compliance with the United States Public Health Profile Library Implementation Guide (US PH Profile Library IG) and support the capability for public health query of patient-level data.</P>
                    <P>We propose that Health IT Modules certified to § 170.315(g)(20) support generalizable and extensible capabilities and standards to support a public health transition to FHIR. These foundational FHIR capabilities will support transmission of relevant data to public health entities.</P>
                    <HD SOURCE="HD3">Costs</HD>
                    <P>These tasks to develop § 170.315(g)(20) have their own level of effort and these estimates are detailed in Tables 63 to 65 below and are based on the following assumptions:</P>
                    <P>1. Health IT developers will use the same labor costs and data models. Table 56 shows the estimated labor costs per product to develop § 170.315(g)(20). 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 58.</P>
                    <P>2. We estimate that 130 products certified by 112 developers will be affected by our proposal. These estimates are a subset of the total estimated health IT developers and certified products we estimated above.</P>
                    <P>The estimate of 130 products certified by 112 developers is derived as follows. We estimate that, in total, 387 health IT developers will certify 521 health IT products impacted by this rulemaking. However, not all these developers and products will certify § 170.315(g)(20) and need to meet the proposed requirements. As of the end of 2022, 29% of developers and 25% of products certified the “standardized API criterion for patient and population services” and one of three public health certification criteria: (1) “immunizations”; “syndromic surveillance”; or “reportable labs”. Since this is a new certification criterion with novel capabilities, our estimate is based off the best proxy of what developers would certify what products to this certification criterion. We determined that the “standardized API” certification criterion was a close proxy to this criterion's capabilities, and we modified that proxy by a product's certification to one of the three above public health certification criteria, which are all probable use cases for public health data exchange this certification criterion is proposed to facilitate. 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 certification 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 $127.82.</P>
                    <BILCOD>BILLING CODE 4150-45-P</BILCOD>
                    <GPH SPAN="3" DEEP="632">
                        <PRTPAGE P="63731"/>
                        <GID>EP05AU24.063</GID>
                    </GPH>
                    <GPH SPAN="3" DEEP="553">
                        <PRTPAGE P="63732"/>
                        <GID>EP05AU24.064</GID>
                    </GPH>
                    <GPH SPAN="3" DEEP="162">
                        <PRTPAGE P="63733"/>
                        <GID>EP05AU24.065</GID>
                    </GPH>
                    <GPH SPAN="3" DEEP="253">
                        <GID>EP05AU24.066</GID>
                    </GPH>
                    <BILCOD>BILLING CODE 4150-45-C</BILCOD>
                    <P>The cost to a health IT developer to develop § 170.315(g)(20) for their Health IT Modules would range from $153,384 to $747,747 per product, on average. Therefore, assuming 130 products overall and a labor rate of $127.82 per hour, we estimate that the total cost to all health IT developers would, on average, range from $19.9 million to $97.2 million.</P>
                    <HD SOURCE="HD3">Benefits</HD>
                    <P>The proposed updates have a wide range of benefits for end-users of health IT (such as physicians, pharmacists, public health practitioners) and the patient populations they serve. While current standards support simple, single-patient, event-based submission of data from healthcare to public health, adopted technology does not adequately support more complex data exchange use cases, such as bulk exchange of patients who received a specific vaccine. The shift to FHIR is needed to support a wide-scale public health response and adoption of FHIR will reduce burden of implementation and maintenance for data exchange between and among health care organizations, providers, and public health agencies.</P>
                    <P>
                        Research demonstrated that a trigger to a public health agency—in this instance, a positive lab report—could then be followed by a query back to the EHR, and data relevant to the condition were shared in an electronic case report.
                        <SU>426</SU>
                        <FTREF/>
                         This approach aided in more complete case reports, including demographic and clinical information, such as medications, symptoms, and diagnoses, and also resulted in only specific, relevant information being shared with the PHA.
                    </P>
                    <FTNT>
                        <P>
                            <SU>426</SU>
                             Mishra N, Duke J, Karki S, Choi M, Riley M, Ilatovskiy AV, Gorges M, Lenert L. A Modified Public Health Automated Case Event Reporting Platform for Enhancing Electronic Laboratory Reports With Clinical Data: Design and Implementation Study. J Med internet Res. 2021 Aug 11;23(8):e26388. doi: 10.2196/26388. PMID: 34383669; PMCID: PMC8387889.
                        </P>
                    </FTNT>
                    <P>
                        Such an approach would allow proactive surveillance and provide public health authorities with the complete data needed to perform public health outreach and other activities. The direct access to relevant, appropriate data is possible using APIs, rather than passive, inflexible technology that sends pre-defined data sets based on a trigger, or that requires the manual intervention of a clinician. Such FHIR functions, including newer functionalities like FHIR based Subscriptions, will reduce the burden of implementation and 
                        <PRTPAGE P="63734"/>
                        maintenance long-term, particularly for public health reporting, as the industry is able to move away from multiple, custom point-to-point connections.
                    </P>
                    <P>While the benefits of many of these modifications are not quantifiable at this time, we expect the resulting improvements to interoperable exchange of health information to significantly benefit end users of health IT and their patient populations and improve the quality of health care provided. Health IT users will benefit from the new certified criterion through increased standardization and public health data interoperability.</P>
                    <HD SOURCE="HD3">14. Bulk Data Enhancements</HD>
                    <P>We propose to adopt the HL7 FHIR Bulk Data Access (v2.0.0: STU 2) implementation specification (Bulk v2 IG) in § 170.215(d)(2), which would replace the current Bulk v1 implementation guide established as the standard in § 170.215(a)(3). V2.0.0 is for the most part backward compatible with v1 and builds on v1 with additional features (optional parameters including, _elements, Patient, and includeAssociatedData) and filter parameters (_since).</P>
                    <P>Through adoption of the Bulk v2 IG, we propose to require server support for the “group-export” “OperationDefinition”, which enables developers engaging with § 170.315(g)(10)-certified Health IT Modules to obtain FHIR resources for a group of patients specified through various filter parameters, for testing and certification. Adoption of the “group-export” “OperationDefinition” for certification also entails adoption of the “_since” query parameter, which allows users to export only FHIR resources that have been modified after a specified date and was not required for client or server in v1 but is now required for server in the v2 IG.</P>
                    <P>Additionally, we propose to require server support for the “_type” query parameter, which allows FHIR resources for export to be filtered by resource type and is currently specified as an optional parameter for both server and client.</P>
                    <HD SOURCE="HD3">Costs</HD>
                    <P>These tasks have their own level of effort, and these estimates are detailed in Tables 59 to 61 and are based on the following assumptions.</P>
                    <P>1. Health IT developers will use the same labor costs and data models. Table 59 shows the estimated labor costs per product to update the new FHIR Bulk Data Access implementation specification and develop server support for the _type query parameter. 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 61.</P>
                    <P>2. We estimate that 224 products certified by 182 developers will be affected by our proposal. These estimates are a subset of the total estimated number of health IT developers and certified products we estimated above.</P>
                    <P>The estimate of 224 products certified by 182 developers is derived as follows. We estimate that, in total, 387 health IT developers will certify 521 health IT products impacted by this rulemaking. However, not all these developers and products certify to the Standardized API certification criterion which adopts the bulk data technical functionality and need to meet the proposed requirements. As of the end of 2022, 43% of developers and 47% of products certified to the Standardized API certification criterion. We applied this modifier to our total developer and product estimate as an overall estimate of the number of developers and products impacted by the proposed modifications to the certification criterion.</P>
                    <P>
                        3. According to the May 2022 BLS occupational employment statistics, the mean hourly wage for a “Software Developer” is $63.91.
                        <SU>427</SU>
                        <FTREF/>
                         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 $127.82.
                    </P>
                    <FTNT>
                        <P>
                            <SU>427</SU>
                             
                            <E T="03">https://www.bls.gov/oes/current/oes151252.htm.</E>
                        </P>
                    </FTNT>
                    <BILCOD>BILLING CODE 4150-45-P</BILCOD>
                    <GPH SPAN="3" DEEP="512">
                        <PRTPAGE P="63735"/>
                        <GID>EP05AU24.067</GID>
                    </GPH>
                    <GPH SPAN="3" DEEP="187">
                        <PRTPAGE P="63736"/>
                        <GID>EP05AU24.068</GID>
                    </GPH>
                    <GPH SPAN="3" DEEP="113">
                        <GID>EP05AU24.069</GID>
                    </GPH>
                    <BILCOD>BILLING CODE 4150-45-C</BILCOD>
                    <P>The cost to a health IT developer to implement these bulk data enhancements for their Health IT Modules would range from $19,173 to $95,865 per product, on average. Therefore, assuming 224 products overall and a labor rate of $127.82 per hour, we estimate that the total cost to all health IT developers would, on average, range from $4.29 million to $21.47 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>
                        The benefits of adopting support for the new standard for FHIR Bulk Data Access are difficult to quantify. We believe the adoption of the new standards in the Bulk FHIR v2 IG and server support of the optional _ type query parameter would benefit providers and patients, as well as the overall public. Bulk FHIR group export functionalities have a variety of use cases, such as, clinical research, and reporting for clinical quality measures. The group export functionality has already been successfully implemented by many organizations, including in CMS' bulk export APIs for “data at the point of care,” in which patients are grouped by provider and care timeframes.
                        <SU>428</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>428</SU>
                             
                            <E T="03">https://link-springer-com.ezproxyhhs.nihlibrary.nih.gov/chapter/10.1007/978-3-030-91563-6_10.</E>
                        </P>
                    </FTNT>
                    <P>
                        We believe that the standards update to the Bulk FHIR v2 IG would not place significant additional burden on developers. As noted in the proposal, new requirements in the Bulk v2 IG are increments to the v1 IG, and many are out of scope for testing and certification. Adoption of Bulk FHIR group export, including support of the _ since parameter, as well as support for the _ type query parameter is already well underway, and the _ since parameter is even better clarified in the v2 IG. In the same 2020 study, researchers surveyed various companies (including payers, EHR and cloud vendors, research organizations, and developers) implementing SMART/HL7 FHIR Bulk Data to assess the state of the API's implementation.
                        <SU>429</SU>
                        <FTREF/>
                         18 of 19 survey respondents noted that they had implemented (5) or were making progress towards implementing (13) the group export functionality. 17 of 19 respondents indicated that their organization had “implemented” or had “in progress” the Bulk filter “_ type” parameter. Only a slightly smaller portion (16 of 19) had indicated that they had implemented or were in progress of implementing the Bulk filter “_ since” parameter. As of 2020 Q2, organizations were already making substantial progress towards adoption, so these additional requirements for certification and testing are not expected to be unusually burdensome. Further, as mentioned in the proposal, by Spring 2023, 73.7% of certified Bulk FHIR modules supported the optional _ type parameter.
                    </P>
                    <FTNT>
                        <P>
                            <SU>429</SU>
                             
                            <E T="03">https://www.ncbi.nlm.nih.gov/pmc/articles/PMC8661398/.</E>
                        </P>
                    </FTNT>
                    <P>Within the same study, survey respondents were asked to indicate hurdles to Bulk FHIR implementation. Major concerns expressed included processing time for data export, choosing breakpoints to divide large data files, granular access to specified FHIR resources, and opportunities for reducing the costs to host data. We believe that these concerns are addressed in the contents of this proposal.</P>
                    <P>
                        The primary additional functionality offered through server support for the “group-export” “OperationDefinition” is filtering by date with the “_ since” parameter. The _ since parameter is expected to produce efficiency in applications in the context of the previously mentioned use cases, as it 
                        <PRTPAGE P="63737"/>
                        will allow for incremental data export, reductions in the amount of data transferred, and prevention of duplication of data transferred. As data are updated, FHIR resources modified within a particular timeframe can be exported, preventing the need to repeatedly export a full dataset when data is being followed and repeatedly shared over time. In addition to preventing the recipient of the data from needing to spend valuable time resources sifting through data to identify data of particular interest (based on the specified timeframe) and delete duplicate data that may have already been received through a previous export, limitations on the amount of data exported through use of the _ since parameter can prevent exports from taking up valuable storage on a user's machine when unnecessary data is otherwise included. We expect the same benefit from adoption of the _ type parameter.
                    </P>
                    <P>Furthermore, we believe our proposals offer opportunities for increased efficiency in these spaces, specifically in contexts where Bulk FHIR group export functionalities are used. Use of the _ since and _ type parameters for group export of FHIR resources is anticipated to lead to improvements in API performance because it allows for a more specified group of resources to be exported, thus limiting the time required for export and improving efficiency. Server support of the _ type parameter for querying in preparation for group export is further expected to have benefits for privacy and security, as specifying FHIR resource types for export limits the risk of exporting sensitive or confidential data, thereby preventing inadvertent harm to patients through exposure of private data. Therefore, these proposals pose an opportunity to address needs indicated in the aforementioned survey.</P>
                    <P>
                        The group export requirement is anticipated to meet existing needs across Bulk FHIR use cases with respect to limiting the quantity of data exported through additional specification. In one study assessing the feasibility of using of Bulk FHIR queries to get COVID-19 vaccination registry information to public health workers performing patient follow-up after vaccines and to schedule vaccination appointments, the researchers found that the specifications in the current Bulk FHIR standard for patient data export was clunky and not scalable for public health purposes, which in the context of using data to facilitate response to the COVID-19 pandemic would have typically required the export of records for thousands of individuals.
                        <SU>430</SU>
                        <FTREF/>
                         Because of this, these researchers found the need to utilize an optional group extension that allowed the specification of particular patient groups for data export. This demonstrates a use case with a practical need for expansion of the standard through adoption of the Bulk v2 IG, and therefore also server support for the “group-export” “OperationDefinition”.
                    </P>
                    <FTNT>
                        <P>
                            <SU>430</SU>
                             
                            <E T="03">https://academic.oup.com/jamia/article/30/3/551/6874797.</E>
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">15. New Requirements To Support Dynamic Client Registration Protocol in the Program</HD>
                    <P>We propose to revise the application programming interface (API) certification criterion in § 170.315(g)(10) and the API Conditions and Maintenance of Certification requirements in § 170.404 by adding requirements to support dynamic client registration for patient-facing applications. We propose to adopt several specific sections of the HL7 UDAP Security for Scalable Registration, Authentication, and Authorization 1.0.0 implementation guide to support these revisions to § 170.315(g)(10) and corresponding API Conditions and Maintenance of Certification requirements. This proposal would facilitate an individual's timely access to their health information using an application of their choice by providing a more uniform, standardized, and automated registration pathway for patient-facing applications.</P>
                    <HD SOURCE="HD3">Costs</HD>
                    <P>This section describes the estimated costs of meeting requirements in the proposed revisions to § 170.315(g)(10), which are detailed in Tables 62 and 63 below and are based on the following assumptions:</P>
                    <P>1. Health IT developers will use the same labor costs and data models. Table 62 shows the estimated labor costs per product to make the proposed updates in § 170.315(g)(10). 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 63.</P>
                    <P>2. We estimate that 224 products certified by 182 developers will be affected by our proposal. These estimates are a subset of the total estimated number of health IT developers and certified products we estimated above. The estimate of 224 products certified by 182 developers is derived as follows. We estimate that, in total, 387 health IT developers will certify 521 health IT products impacted by this rulemaking. However, not all these developers and products certify to § 170.315(g)(10) certification criterion and need to meet the proposed requirements. As of the end of 2022, 47% of developers and 43% of products certified to § 170.315(g)(10) certification criterion. We applied this modifier to our total developer and product estimate as an overall estimate of the number of developers and products impacted by the proposed modifications to the certification criterion.</P>
                    <P>
                        3. According to the May 2022 BLS occupational employment statistics, the mean hourly wage for a “Software Developer” is $63.91.
                        <SU>431</SU>
                        <FTREF/>
                         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 $127.82.
                    </P>
                    <FTNT>
                        <P>
                            <SU>431</SU>
                             
                            <E T="03">https://www.bls.gov/oes/current/oes151252.htm.</E>
                        </P>
                    </FTNT>
                    <BILCOD>BILLING CODE 4150-45-P</BILCOD>
                    <GPH SPAN="3" DEEP="504">
                        <PRTPAGE P="63738"/>
                        <GID>EP05AU24.070</GID>
                    </GPH>
                    <GPH SPAN="3" DEEP="394">
                        <PRTPAGE P="63739"/>
                        <GID>EP05AU24.071</GID>
                    </GPH>
                    <BILCOD>BILLING CODE 4150-45-C</BILCOD>
                    <P>In addition to the estimated costs, we believe this proposal would create cost savings for certified API developers. API developers currently support a manual app registration process where they must review and confirm all registrations individually. The proposed dynamic registration process would replace a manual verification of each app developer by the certified API developers with a trust framework wherein an app developer with a certification for a given trust framework would be granted automatic registration. The proposed process would reduce burden on certified API developers to verify all registrations individually. Table 64 shows the projected cost savings over a 10-year period to all certified API developers.</P>
                    <P>
                        We estimate that on average, there would be 50 app registrations per certified product per year. This estimate is based on a study of public app galleries and the number of new apps, on average, that are available to EHR users each year.
                        <SU>432</SU>
                        <FTREF/>
                         Because this average is based on public marketing of apps approved for display by EHR vendors, it may underestimate the true number of apps that register, but do not go into production each year. The average may also be overestimated, because it's based on app integrations for market leading EHR vendors and may not be representative of app registrations for smaller EHR vendors. We request comment on this measurement approach and accuracy of the number of app registrations a developer of certified health IT must verify annually.
                    </P>
                    <FTNT>
                        <P>
                            <SU>432</SU>
                             Barker W., Johnson C., The ecosystem of apps and software integrated with certified health information technology.Journal of the American Medical Informatics Association 28(11), 2021, 1-6.
                        </P>
                    </FTNT>
                    <GPH SPAN="3" DEEP="197">
                        <PRTPAGE P="63740"/>
                        <GID>EP05AU24.072</GID>
                    </GPH>
                    <P>The cost to a health IT developer to meet the proposed requirements would range from $116,316 to $171,279 per product, on average. Assuming 224 products overall and a labor rate of $127.82 per hour, we estimate that the total cost for all products would, on average, range from $26 to $38.3 million. The cost savings to a health IT developer to meet the proposed requirements would range from $29,610 to $59,220 per product, on average, over a 10-year time horizon. Assuming 224 products overall and a labor rate of $59.22 per hour, we estimate that the cost savings for all products would, on average, range from $6.6 to $13.3 million, over a 10-year time horizon, resulting in an overall net cost to health IT developers of $19.4 to $25.1 million.</P>
                    <HD SOURCE="HD3">Benefits</HD>
                    <P>We believe this proposal would benefit health care developers and the health IT industry. The proposed updates would streamline the currently manual and non-standardized process for application registration for the § 170.315(g)(10) certification criterion for patient-facing apps. The current manual process creates administrative burden and is difficult to scale when registering for more than one endpoint. With dynamic registration, applications can obtain a certificate that can then be used across all endpoints that support that certificate, taking the industry one step closer to the goal of APIs being usable “without special effort” under the Cures Act.</P>
                    <P>We believe this proposal would create financial benefits to app developers. Current app registration processes are manual, requiring app developers to complete their registration and wait for the certified API developer or API information source to manually verify and approve their registration. The actual process of verification and approval may take minutes, but the wait and backlog of registrations may create undue burden for app developers to successfully register their app to begin testing and development using the EHR's APIs. The proposed registration process, as we detail in the cost savings estimated for certified API developers, reduces this time and automates the registration process with immediate verification. App developers would see direct benefits from this new registration process through time savings due to decreased wait times and uncertainty about verification timelines. Table 65 below shows the estimated benefits for app developers realized from the new proposed registration process.</P>
                    <GPH SPAN="3" DEEP="154">
                        <GID>EP05AU24.073</GID>
                    </GPH>
                    <P>
                        The estimated quantified benefits assume several factors: (1) app registrations may need to be completed for all distinct FHIR electronic endpoints; (2) a computer user support specialist would be needed to complete the process; and (3) benefits will begin to accrue in the third year after this rulemaking is finalized. The estimated 
                        <PRTPAGE P="63741"/>
                        number of endpoints per developer was calculated using public data available through the ONC FHIR API Monitoring System or “Lantern”.
                        <SU>433</SU>
                        <FTREF/>
                         The data are as of the end of 2023 and represent all endpoints available from certified API developers (n = 224). The endpoints were tested by the Lantern system to ensure they were accessible when randomly queried and a conformant FHIR Capability Statement was fetched upon a successful query of the endpoint. We request comment on whether endpoints represent the best proxy for volume of app registrations and if the proposed endpoint calculation is sound. We estimate that the average time for an app developer to register for each endpoint would take from 15 to 30 minutes. We then multiplied the effort for one app developer to register their app for all endpoints by the average number of app registrations per developer per year estimated in Table 64 for 8 years (the number of years after the proposed registration requirements would be implemented by certified API developers.) We estimate financial benefits from $118.4 million to $236.9 million for app developers in the form of time savings and other reduced costs associated with the effort of manual registration to electronic endpoints. We request comment on this proposed approach and, specifically, request comment on the approximate time to complete the registration process.
                    </P>
                    <FTNT>
                        <P>
                            <SU>433</SU>
                             
                            <E T="03">https://github.com/onc-healthit/onc-open-data/tree/main/lantern-daily-data.</E>
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">16. New Certification Criteria for Modular API Capabilities</HD>
                    <P>We propose to include 14 new certification criteria as modular API capabilities in § 170.315(j). These new certification criteria would be available for certification based on certain contexts or other programs requiring the use of the specified certified capabilities. The first eight of these certification criteria are substantially similar to capabilities currently referenced in § 170.315(g)(10)(iii) through (vii) and the three remaining certification criteria are new to the Program.</P>
                    <FP SOURCE="FP-1">• § 170.315(j)(1): Functional registration</FP>
                    <FP SOURCE="FP-1">• § 170.315(j)(2): Dynamic registration</FP>
                    <FP SOURCE="FP-1">• § 170.315(j)(5): Asymmetric certificate-based authentication for patient access</FP>
                    <FP SOURCE="FP-1">• § 170.315(j)(6): SMART app launch user authorization</FP>
                    <FP SOURCE="FP-1">• § 170.315(j)(7): SMART backend services system authentication and authorization</FP>
                    <FP SOURCE="FP-1">• § 170.315(j)(8): Asymmetric certificate-based system authentication and authorization</FP>
                    <FP SOURCE="FP-1">• § 170.315(j)(9): SMART patient access for standalone apps</FP>
                    <FP SOURCE="FP-1">• § 170.315(j)(10): SMART clinician access for EHR launch</FP>
                    <FP SOURCE="FP-1">• § 170.315(j)(11): Asymmetric certificate-based authentication for B2B user access</FP>
                    <FP SOURCE="FP-1">• § 170.315(j)(20) and § 170.315(j)(21): Workflow triggers for decision support interventions</FP>
                    <FP SOURCE="FP-1">• § 170.315(j)(22): Verifiable health records</FP>
                    <FP SOURCE="FP-1">• § 170.315(j)(23) and § 170.315(j)(24): Subscriptions</FP>
                    <P>The proposed new certification criteria create flexibility to test and certify Health IT Modules and introduce new technical functionalities with synergy with other certification criteria proposed in this rulemaking and already adopted by the Program. For certification criteria § 170.315(j)(1) to (j)(7), these new certification criteria do not increase the level of burden on developers to adopt. Sections 170.315(j)(1) and 170.315(j)(3) to (j)(7) are currently adopted as part of the § 170.315(g)(10) certification criterion and we assume no additional development burden (beyond what has been estimated as part of prior rulemaking where these functionalities were originally adopted and finalized) to adopt these capabilities in this new modular manner. The proposal for “Dynamic Client Registration” would be adopted as part of proposed certification criterion § 170.315(j)(2). This proposal is discussed elsewhere in this regulatory impact analysis. We also request comment on a proposed update to functionalities currently adopted as part of the (g)(10) certification criterion and are proposed to be adopted as individual (j) certification criteria, as discussed above. We propose to update the token revocation policy (as adopted in § 170.315(j)(7): User authorization and (g)(10)) to require authorization revocation for users generally (to include users such as clinicians generally as opposed to only patients.) We request on whether this broader revocation policy will require additional effort to implement, as the underlying functionality to enable it for patients should be very similar for users generally. We believe implementing this update should require de minimis effort and appreciate public comment.</P>
                    <P>Certification criteria § 170.315(j)(20) to (j)(24) propose new technical functionalities. However, this proposed rulemaking does not require adoption of these new certification criteria, specifically. The certification criteria are referenced as conditional or as required functionality for other proposed certification criteria. The impact analyses, below, for these three proposed certification criteria assess the expected level of effort and development tasks required to adopt the new certification criteria, but do not assume required adoption for these certification criteria for any current developers of certified health IT. Where necessary, we reference these development tasks and burden in the related impact analyses of other proposed certification criteria that adopt these new certification criteria and their technical functionalities as necessary functionality to meet their distinct certification requirements.</P>
                    <HD SOURCE="HD3">Workflow Triggers for Decision Support Interventions</HD>
                    <P>We propose to adopt HL7 Clinical Decision Support (CDS) Hooks FHIR Implementation Guide version 2.0 in § 170.215(f) as a mandatory compliance prerequisite to facilitate API-driven workflow triggers for decision support interventions in § 170.315(j)(20) and § 170.315(j)(21). This requirement would establish adoption of a “hook”-based pattern for initiating clinical decision support, either allowing decision support results to be integrated seamlessly into a provider's EHR workflow or launching an interactive CDS application from within the workflow.</P>
                    <P>
                        We additionally propose the integration of standards-based interfaces into § 170.315(j)(20), including the requirement for § 170.315(j)(20)-certified Health IT Modules to support the “patient-view” hook per the standard specified in § 170.215(f). The patient-view hook enables clinicians to retrieve data for individual patients (
                        <E T="03">e.g.,</E>
                         demographics, medical history, pertinent clinical information) as a means of accessing decision support that is customized to an individual patient and more contextually relevant.
                    </P>
                    <HD SOURCE="HD3">Costs</HD>
                    <P>These tasks have their own level of effort, and these estimates are detailed in Table 66 below.</P>
                    <GPH SPAN="3" DEEP="418">
                        <PRTPAGE P="63742"/>
                        <GID>EP05AU24.074</GID>
                    </GPH>
                    <P>
                        These proposals may also impose some costs and challenges that are not easily quantifiable. While some scholars posit that CDS Hooks are in a state of relative immaturity compared to other HL7 standards, their growing popularity suggests further standards development for CDS Hooks is likely on the horizon. Part of the developing maturity level comes from exploration of new hook definitions for workflow trigger points, security best practices, response analytics, and suggestions for improved interoperability for items like recommended prescriptions.
                        <SU>434</SU>
                        <FTREF/>
                         Based on public feedback on ONC's request for information in the HTI-1 Proposed Rule, some commenters expressed concerns for slow real-world adoption of CDS Hooks. Although CDS Hooks is reasonably mature, many developers and other organizations are not using this technology. One review of “original studies describing development of specific CDS tools or infrastructures” using FHIR, SMART, CQL, and CDS Hooks published in 2021 found that only 18% used CDS Hooks. These authors note that CDS Hooks are too early in their life cycles to determine their uptake based on the limited number of studies on them.
                        <SU>435</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>434</SU>
                             
                            <E T="03">https://www.ncbi.nlm.nih.gov/pmc/articles/PMC8324242/.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>435</SU>
                             
                            <E T="03">https://www.ncbi.nlm.nih.gov/pmc/articles/PMC8416232/.</E>
                        </P>
                    </FTNT>
                    <P>Considering this, many commenters were partial to certification requirement rollout for specific use cases, such as prior authorization, immunization decision support, evidenced-based treatment decisions and alternatives, etc. Notably, prior authorization was indicated to be a high priority use case. Furthermore, one market leading EHR developer indicated in RFI comments that it does not believe certification of CDS Hooks is necessary to materially advance interoperability and supports allowing market forces to drive adoption. The developer noted they make CDS Hooks available but is utilized by only about 10% of end users, potentially due to its effect of slowing clinician workflows.</P>
                    <P>
                        There are examples of successful implementations of CDS Hooks, but these implementations are not without challenges. In one study by Dolin et al., the researchers developed a pharmacogenomics CDS service prototype based on the FHIR and CDS Hooks standards.
                        <SU>436</SU>
                        <FTREF/>
                         The researchers noted that they were able to meet their goals of deploying a functional prototype but identified some challenges with CDS Hooks. They found that the process for executing an authenticated query request in a system outside of the EHR from a trigger within 
                        <PRTPAGE P="63743"/>
                        the EHR was very complex and noted constraints on the variety of actionable CDS recommendation types that could be returned from the decision support tool.
                    </P>
                    <FTNT>
                        <P>
                            <SU>436</SU>
                             
                            <E T="03">https://pubmed.ncbi.nlm.nih.gov/30605914/.</E>
                        </P>
                    </FTNT>
                    <P>
                        One randomized control trial assessed the cost of using CDS Hooks to clinician end users. CDS Hooks was shown to be more burdensome to end-users, requiring many clicks and a greater level of effort than other EHR prompts. Based on a cluster RCT in an emergency department using Epic, single-click prompts like ordering HIV screening laboratory tests take less effort and clicks than CDS Hooks. Single-click app launching occurs with some CDS Hooks; for example, the Epic EHR uses CDS Hooks for pop-up alerts. However, single-click launching does not happen for all Epic prompts, including Storyboard prompts (patient summaries that are always displayed in the EHR for an individual patient). Instead of a single click, the user must click on the Storyboard prompt and then eventually access the hyperlink to the hook. Accessing the hyperlink is nonintuitive to most users, which is why the researchers in this study requested Epic to have a single-click for CDS Hooks in the Storyboard prompt.
                        <SU>437</SU>
                        <FTREF/>
                         These challenges faced by end-users suggest that there may be room for growth in CDS Hooks implementations.
                    </P>
                    <FTNT>
                        <P>
                            <SU>437</SU>
                             Ibid.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Benefits</HD>
                    <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 clinician end users and improve the quality of health care provided. Clinicians will benefit from the updates to the standard and to the certified criterion through increased standardization and interoperability of CDS Hooks technology. Certified use of CDS Hooks is expected to facilitate more patient-specific results from clinical decision support tools, assisting providers in a more patient-centric approach to care. Further, we believe that the “patient-view” hook proposed to be required for modular certification is the most mature, as supported by public comment, and that current implementers of CDS Hooks will be able to implement this with limited additional challenge.</P>
                    <P>Based on public feedback on ONC's request for information in the HTI-1 Proposed Rule, commenters were generally more supportive of certification criteria for adoption of the v2.0 specification of FHIR CDS Hooks, as opposed to v1.0. Many also preferred ONC supporting narrow certification criteria related to a particular user guide, as we have specified in this proposal. Specifically, we propose to require just the “patient-view” hook for modular certification. We believe the nature of our proposal addresses some of these concerns. Further, the “patient-view” hook was among the hooks recommended by commenters to use as part of the certification requirements. Given commenter concerns for use-case specific guidance, we propose support for the “patient-view” hook, specifically, given its broad applicability across use cases. We expect the ability to acquire modular certification per in § 170.315(j)(20) through the “patient-view” hook because it is use-case agnostic.</P>
                    <P>Although many argue that adoption is growing slowly for CDS Hooks, based on comments received as part of the HTI-1 Proposed Rule RFI, one commenter expressed their support for modular certification of this technology, noting the belief that it is significantly developed and mature, as well as citing the fact that the CMS Interoperability and Prior Authorization Proposed Rule is dependent on this technology (a large-scale implementation example).</P>
                    <P>
                        Based on public feedback on ONC's request for information in the HTI-1 Proposed Rule, commenters were generally supportive of the utility of CDS Hooks and believed the specification to be mature. Based on the literature, use of CDS Hooks appears to offer utility to patients and providers. In a randomized control trial of CDS Hooks' feasibility to increase use of SMART on FHIR apps, researchers found that CDS Hooks may lead to reduction in usability issues with SMART on FHIR apps.
                        <SU>438</SU>
                        <FTREF/>
                         This would likely create better access to clinical care recommendations on its own, in addition to more complex decision logic due to the use of an external CDS engine through CDS Hooks services that could then be implemented using native EHR CDS approaches. These improvements in CDS could subsequently improve care decisions and patient outcomes. Another likely benefit of CDS Hooks is time savings from interoperability because (similar to SMART on FHIR apps), CDS Hooks can be shared across EHR platforms and health systems.
                    </P>
                    <FTNT>
                        <P>
                            <SU>438</SU>
                             
                            <E T="03">https://www.ncbi.nlm.nih.gov/pmc/articles/PMC9382378/.</E>
                        </P>
                    </FTNT>
                    <P>
                        Beyond the opportunity for clinical decision support tools to facilitate reduced cognitive load and timesaving for providers, another anticipated benefit of CDS Hooks is that it gives clinicians using CDS tools the option to utilize these tools only when needed.
                        <SU>439</SU>
                        <FTREF/>
                         Relatedly, use of CDS Hooks allows decision support results to be accessed at any time during a patient's care, and not only when the results of an ordered lab are received. This is expected to benefit patients by reducing the risk of adverse health events and preventing duplication of lab tests. Due to resulting increases in care efficiency, this is also expected to lead to notable cost-savings for health systems utilizing the CDS Hooks tool.
                    </P>
                    <FTNT>
                        <P>
                            <SU>439</SU>
                             
                            <E T="03">https://www.ncbi.nlm.nih.gov/pmc/articles/PMC7233102/.</E>
                        </P>
                    </FTNT>
                    <P>
                        In one RCT trial, researchers aimed to assess the feasibility of using CDS Hooks to increase SMART on FHIR app utilization. The researchers found that, since the same logic is used for CDS Hooks and SMART on FHIR apps, developer burden can be reduced because CDS Hooks use FHIR as their data model and exchange standard like SMART on FHIR. Morgan et al., advise that to justify the significant time and resources EHR developers must invest in building the hook, development should focus on single-click prompts where the end-user burden is most likely to benefit (however, developer effort is not quantified in this RCT).
                        <SU>440</SU>
                        <FTREF/>
                         CDS Hooks largely addresses this concern, as it uses a hyperlink to SMART on FHIR app that allows users to launch the app in a single click.
                        <SU>441</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>440</SU>
                             
                            <E T="03">https://www.ncbi.nlm.nih.gov/pmc/articles/PMC9382378/.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>441</SU>
                             Ibid.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Verifiable Health Records</HD>
                    <P>We propose in § 170.315(j)(22) that Health IT Modules demonstrate support for creating verifiable SMART Health Cards per the standard in § 170.215(g) and that records are made available to users through these cards. SMART cards allow patients to carry verifiable, portable healthcare data that can easily be shared with a provider via QR code. SMART cards are a form of patient-held records intended to advance interoperability and improve patients' ability to share their healthcare data for treatment in light of challenges with provider-to-provider data exchange.</P>
                    <HD SOURCE="HD3">Costs</HD>
                    <P>From a development perspective, costs are anticipated to be minimized, as code necessary to implement the technology is based on open standards, and components are substitutable. However, these tasks have their own level of effort, and these estimates are detailed in Table 67 below:</P>
                    <GPH SPAN="3" DEEP="452">
                        <PRTPAGE P="63744"/>
                        <GID>EP05AU24.075</GID>
                    </GPH>
                    <P>The cost to adopt the SMART Health Cards standard and make verifiable records available to users is difficult to estimate given the current state of SMART Health Card implementations. Beyond the cost of development, some additional concerns with certification have been expressed by major Health IT developers and policy organizations. The public was asked to provide comment on ONC's “SMART Health Links Request for Information” in the HTI-1 Proposed Rule, and several major developers and EHR companies responded with their feedback. Many commenters indicated that they were supportive of the advancement of SMART Health Cards but not of related certification, citing the current lack of maturity of the technology as well as the lack of necessity for certification in high-value use cases, noting that the market should be left to fuel the demand for this technology. One market leading EHR expressed its opposition to certification of SMART Health Cards due to a perceived lack of standards maturity, need for a clear use case, and need for greater adoption by patients. One commenter highlighted that the focus needs to first be on defining use cases of this technology; importantly, there are no known implementations of SMART Health Cards beyond the public health (particularly, the COVID-19 pandemic) use case. One market leading EHR expressed additional concerns about certification of SMART Health Cards in the context of an unfolding landscape in which privacy concerns that must be considered may not yet be identifiable, noting that “ensuring trusted and secure links to such cards raises challenges that need to be fully addressed to ensure appropriately authorized users to access the highly sensitive PHI.” In general, commenters had interest in this technology and its uses being better defined before moving towards certification. To summarize, companies expressed concerns about rushing into certification of SMART Health Cards when use cases still need to be defined, and thus demand is not present, and given unidentified security concerns that might be exposed with more adoption fueled naturally by market demand.</P>
                    <P>
                        We anticipate some additional challenges in adopting this technology that were not included in the comments 
                        <PRTPAGE P="63745"/>
                        discussed above.
                        <SU>442</SU>
                        <FTREF/>
                         Tradeoffs exist between privacy and the strength of identity binding for SMART Health Cards technology, so developers may face challenges ensuring the safety of individuals' health information while binding cards to a real-world identity. SMART Health Cards also rely on the establishment of “trust frameworks” so that clinicians who are presented a QR code with patient data can verify that this record is from a trustworthy source. This may be difficult in the future as multiple frameworks with differing goals launch.
                    </P>
                    <FTNT>
                        <P>
                            <SU>442</SU>
                             
                            <E T="03">https://docs.google.com/presentation/d/1Ib8lxZWgJ8IIq7NEzbV4_R5s1nRD3pEv/present?slide=id.p5.</E>
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Benefits</HD>
                    <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 health care provided. Providers and patients will benefit from the updates to the standard and to the certified criterion through increased standardization and interoperability of patient health data through a verifiable form of patient-held records.</P>
                    <P>
                        During the COVID-19 pandemic, 12 IT companies (led by Microsoft and Oracle) came together to form the Vaccination Credential Initiative (VCI), which used the SMART Health Cards specification to allow patients to hold verifiable COVID-19 vaccination records or “passports.” 
                        <SU>443</SU>
                        <FTREF/>
                         Of note, a few of the companies and organizations that provided comment to the request for information in ONC's HTI-1 Proposed Rule were involved in this effort. Likely due to the recency of the COVID-19 pandemic and the kick-off of such efforts, there is little in the literature that assesses the performance of these verifiable records. However, the vaccine passports are thought to have created a sense of validity of COVID-19 vaccine records at a time when many paper records were being falsified.
                    </P>
                    <FTNT>
                        <P>
                            <SU>443</SU>
                             
                            <E T="03">https://www.ncbi.nlm.nih.gov/pmc/articles/PMC9759417/.</E>
                        </P>
                    </FTNT>
                    <P>
                        Because of the low levels of current adoption of SMART Health Cards in use cases beyond the COVID-19 public health emergency, tangible improvements in health outcomes due to the use of SMART Health Cards (if any exist) are unknown. However, we anticipate many benefits from the adoption and certification of this technology. First, SMART Health Cards offer an opportunity to engage patients in the self-management of their own health data, which is expected to lead to improved outcomes due to the resulting improvements in patient-provider communication and availability of verifiable patient-held records. This may particularly benefit patients with serious chronic conditions, as these individuals may be more likely to adopt personal use of patient-held records, such as SMART Health Cards.
                        <SU>444</SU>
                        <FTREF/>
                         Despite ONC's ongoing efforts for and clear improvements with respect to interoperability in the healthcare sector, we acknowledge that interoperable exchange of healthcare data is not perfect, and providers generally do not have all of a patient's diagnostic and treatment history. Use of patient-held health records (of which SMART Health Cards are an example) prevents information asymmetry with provider and improved communication with provider as a result, which we expect to enable providers to make more informed and effective treatment decisions.
                        <SU>445</SU>
                        <FTREF/>
                         Patient engagement has improved with improvements in Health IT, and we expect the adoption of SMART Health Cards (a technology that fosters patient engagement by placing control over records sharing into the hands of the patient) to lead to improved patient outcomes.
                        <SU>446</SU>
                        <FTREF/>
                         One systematic review of the impact of Health IT on “patient engagement and behavior change” published in 2016 found encouraging results. Assessing 170 studies in total, the researchers found that 4 in 5 showed improved patient engagement and nearly 9 in 10 found improvements in patient behavior due to continuing advancements in health information technology.
                        <SU>447</SU>
                        <FTREF/>
                         When additional technologies are provided that allow patients to become more engaged, patients may be more invested in better personal health-decision making.
                    </P>
                    <FTNT>
                        <P>
                            <SU>444</SU>
                             
                            <E T="03">https://academic.oup.com/jamia/article/18/4/515/736676.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>445</SU>
                             
                            <E T="03">https://www-sciencedirect-com.ezproxyhhs.nihlibrary.nih.gov/science/article/pii/S0738399103001848#aep-section-id31.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>446</SU>
                             
                            <E T="03">https://medinform.jmir.org/2016/1/e1/.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>447</SU>
                             
                            <E T="03">https://medinform.jmir.org/2016/1/e1/.</E>
                        </P>
                    </FTNT>
                    <P>
                        Patient control over their data sharing through adoption of SMART Health Cards technology offers further opportunities to respect patient preferences in the sharing of sensitive information by preventing the over-sharing of data. Based on a recent Pew study involving focus groups of patients, individuals are interested in most of their health information being shareable between providers but are less comfortable of more sensitive data being shared (
                        <E T="03">e.g.</E>
                         data points relating to substance misuse, behavioral and mental health, and social needs).
                        <SU>448</SU>
                        <FTREF/>
                         Some participants expressed concern that stigmatizing information may fuel discrimination, which is expected to negatively affect care outcomes and patient comfort with seeking care. SMART Health Cards offer patients the opportunity to share verifiable records with their providers very easily but also preserves the element of choice, thus respecting patient preferences in the continuity of their care and offering opportunities to prevent the sharing of data that is deemed irrelevant for care.
                    </P>
                    <FTNT>
                        <P>
                            <SU>448</SU>
                             
                            <E T="03">https://www.pewtrusts.org/en/research-and-analysis/issue-briefs/2020/03/patients-seek-better-exchange-of-health-data-among-their-care-providers.</E>
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Subscriptions</HD>
                    <P>We propose that Health IT Modules certified to § 170.315(j)(23) and § 170.315(j)(24) demonstrate support for FHIR-based API subscriptions according to the HL7 FHIR Subscriptions Framework. We specifically propose the adoption of the Subscriptions R5 Backport Implementation Guide version 1.1.0 (Backport IG) in § 170.215(h)(1) as a baseline standard conformance requirement in § 170.315(j)(23) and § 170.315(j)(24). FHIR Subscriptions allow a server to notify a user when information has been added or altered within a record, as well as offers the ability to submit a payload with a notification. We further propose the following requirements for certification of a Health IT Module in § 170.315(j)(23) and § 170.315(j)(24):</P>
                    <P>1. Conformance to the “R4/B Topic-Based Subscription” profile detailed in the as specified in the Backport IG. This includes the need to demonstrate support for “must support” elements.</P>
                    <P>2. Adoption of both the Patient-Update and Encounter-Create Subscription topics as minimum requirements for server support.</P>
                    <P>3. Conformance to the R4 “Server CapabilityStatement” included in the Backport IG.</P>
                    <P>a. Server support of create, update and delete interactions for Subscription resources (create and delete are currently optional).</P>
                    <P>4. Server support of id-only payload notification bundles.</P>
                    <P>5. At a minimum, support of the REST-hook Subscription channel as a means of notifying subscribers of the availability of new results.</P>
                    <HD SOURCE="HD3">Costs</HD>
                    <P>These tasks have their own level of effort, and these estimates are detailed in Table 68 below: </P>
                    <GPH SPAN="3" DEEP="494">
                        <PRTPAGE P="63746"/>
                        <GID>EP05AU24.076</GID>
                    </GPH>
                    <P>
                        We acknowledge that these costs may be difficult to estimate given the current state of FHIR Subscription implementations ONC requested public comment in a “FHIR Subscriptions Request for Information” in the HTI-1 Rule proposal, and some commenters expressed concern for cost. One commenter specifically indicated a concern for costs to implement and a need for more information on relevant use cases, given a current lack of real-world implementations of FHIR Subscriptions according to the specifications in the R5 Backport IG. Further, we do not know the extent to which costs and benefits may balance one another. Subscriptions are intended to provide active event notifications to users immediately when data in a record is updated or changed.
                        <SU>449</SU>
                        <FTREF/>
                         However, academic literature on this topic does not currently reflect concrete benefits of this notification service. We request comment on these cost estimates, in particular the burden hours and necessary tasks to develop this functionality.
                    </P>
                    <FTNT>
                        <P>
                            <SU>449</SU>
                             
                            <E T="03">https://build.fhir.org/ig/HL7/fhir-subscription-backport-ig/.</E>
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Benefits</HD>
                    <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 patients, providers, and health care workers and improve the quality of health care provided. Currently, patient access and decision support applications need to periodically poll § 170.315(g)(10)-certified APIs to check for updates to patient records. Using the HL7 FHIR Subscriptions Framework, these apps can receive notifications when relevant updates are available. 
                        <PRTPAGE P="63747"/>
                        This means that patient apps and decision support apps can have more timely, real-time access to the latest records, ensuring that they always have the most up-to-date information. The current API polling model requires applications to make requests to the server, even when there are no updates available. This can result in unnecessary network traffic and resource utilization. Using HL7 FHIR Subscriptions, applications receive notifications when updates are available, and can use these notifications to make server queries to receive patient record updates, reducing the overall network traffic and resource usage. Provider applications can similarly benefit by receiving real-time notifications to update decision support modules and other supporting services.
                    </P>
                    <P>Public health reporting can also be supported with the HL7 FHIR Subscriptions Framework. Currently, implementers seeking to support projects like electronic case reporting must configure one-off solutions to support case report triggers in their EHR systems. While the triggering criteria can be standards-based using value sets like the electronic case reporting Reportable Conditions Trigger Code, the process for sending notifications currently relies on non-standardized or manual solutions. Support for the HL7 FHIR Subscriptions Framework will enable systems to readily support a variety of standards-based public health reporting and will provide the baseline functionality required for future public health implementation guides to be developed that will help ensure that vital public health information is timely and available when needed. Additionally, since the HL7 FHIR Subscriptions Framework is based in HL7 FHIR, the servers and applications are able to use a standardized language to communicate the criteria used for triggering subscription notifications.</P>
                    <P>
                        FHIR Subscriptions have a maturity level of 3 (on a 5-point Likert scale) and is currently in Trial Use. Although it's been deemed ready for use in production systems, it has not seen widespread use in production.
                        <SU>450</SU>
                        <FTREF/>
                         According to the HL7 website, this would mean that the “FMM2 + the artifact has been verified by the work group as meeting the Conformance Resource Quality Guidelines; has been subject to a round of formal balloting; and has at least 10 distinct implementer comments recorded in the tracker drawn from at least 3 organizations resulting in at least one substantive change.” 
                        <SU>451</SU>
                        <FTREF/>
                         HL7's website further states that subscribers (in this case, developers) typically would not need to implement many channel types, so it is unlikely that these developers would spend a significant portion of time with trial and error.
                        <SU>452</SU>
                        <FTREF/>
                         We specifically propose to require support only for the REST-hook channel for modular certification in § 170.315(j)(22). We note in the proposal that this channel uses the RESTful model, is used extensively in the FHIR standard, and is considered the lowest bar for implementation. Given these points, we believe the burden to developers who wish to achieve modular certification in § 170.315(j)(22) to be minimized. As a note, no academic literature has been found that assesses end-user burden of event notifications/Subscriptions R5 Backport IG.
                    </P>
                    <FTNT>
                        <P>
                            <SU>450</SU>
                             
                            <E T="03">https://build.fhir.org/subscriptions.html.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>451</SU>
                             
                            <E T="03">https://build.fhir.org/versions.html#maturity.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>452</SU>
                             
                            <E T="03">https://build.fhir.org/subscriptions.html.</E>
                        </P>
                    </FTNT>
                    <P>Although the literature does not highlight clear, quantifiable benefits of FHIR Subscription services, we anticipate FHIR Subscriptions to ease interorganizational transactions through the functionality to transmit a payload along with a notification, as well as to reduce the burden of reporting across several public health use cases. Subscriptions are expected to be relevant in clinical, public health, administrative, and research use cases, and we believe Subscriptions will play a role in automating case and health care survey reporting in these contexts, thus reducing provider burden.</P>
                    <P>The public was asked to provide comments on ONC's FHIR subscriptions request for information in the HTI-1 rule proposal, and responses were considered in the development of proposals pertaining to FHIR subscriptions in HTI-2. Commenters generally noted that the FHIR version R5 Backport IG as a better option for implementation guidance than the R4B IG. Feedback received also included recommendations to start with small defined use cases and a subset of topics thought to be most beneficial. We have specifically proposed support for two Subscription topics—Patient-Update and Encounter-Create, which can be implemented easily through canonical URLs. Our proposals align with these recommendations to begin with a simplified and clearly specified approach to adoption required for modular certification.</P>
                    <HD SOURCE="HD3">17. Multi-Factor Authentication Certification Criterion</HD>
                    <P>ONC proposes to revise the “multi-factor authentication” (MFA) certification criterion in § 170.315(d)(13) and accordingly update the privacy and security (P&amp;S) certification framework in § 170.550(h). The proposed update would revise our MFA certification criterion by replacing our current “yes” or “no” attestation requirement with a specific requirement to support multi-factor authentication and configuration for three certification criteria: “view, download, transmit to 3rd party” (§ 170.315(e)(1)); “standardized API for patient and population services” (§ 170.315(g)(10)) (for “patient facing” access); and “electronic prescribing” (§ 170.315(b)(3)). We believe these updates match industry best practices for information security, particularly for important authentication use cases in health IT. Finally, we propose to remove references to § 170.315(d)(13) in § 170.550(h)(3) for all certification criteria except for § 170.315(e)(1), (g)(10), and (b)(3).</P>
                    <HD SOURCE="HD3">Costs</HD>
                    <P>The currently adopted MFA certification criterion instructs developers to attest “yes” or “no” that they support multi-factor authentication. An analysis of the Certified Health IT Product List (CHPL), as of the end of 2022, shows that 43% of developers (comprising 44% of products required to comply with the certification criterion) attested “yes” that they support multi-factor authentication. These results do not confirm our priors, when ONC finalized the ONC Cures Act Final Rule, that most, if not nearly all developers and products, would support MFA. The proposed revision requires most of the developers who must comply with the current adopted certification criterion with actual MFA functionality versus an attestation of its use.</P>
                    <P>The proposed revised certification criterion will require developers who certify “view, download, transmit to 3rd party” (§ 170.315(e)(1)); “standardized API for patient and population services” (§ 170.315(g)(10)) (for “patient facing” access); and “electronic prescribing” (§ 170.315(b)(3)) to comply with the revised certification criterion. Similar to developers and products overall that must meet the MFA certification criterion, 43% of these developers of these products that meet any of these three certification criteria attested “yes” that they support multi-factor authentication.</P>
                    <P>The proposed revisions include:</P>
                    <P>• Revise § 170.315(d)(13)(i) to require Health IT Module support for authentication, through multiple elements of the user's identity, according to industry recognized standards.</P>
                    <P>
                        • Revise § 170.315(d)(13)(ii) to require that Health IT Modules provide 
                        <PRTPAGE P="63748"/>
                        functionality that allows users (
                        <E T="03">e.g.,</E>
                         providers and patients) to configure, enable and disable these multi-factor authentication capabilities.
                    </P>
                    <P>• Revise § 170.550(h)(3) to require compliance for § 170.315(d)(13) for § 170.315(e)(1), § 170.315(g)(10), and § 170.315(b)(3). No other certification criteria will require compliance to § 170.315(d)(13).</P>
                    <P>The estimated costs will vary depending on current developer attestations to the MFA certification criterion. We assume an overall lower level of burden for developers who attested “yes” to support MFA to comply with this revised certification criterion. We separate out the costs for these developers from those that attested “no” to support MFA.</P>
                    <P>These tasks have their own level of effort and these estimates are detailed in Tables 69 to 71 below and are based on the following assumptions:</P>
                    <P>1. Health IT developers will use the same labor costs and data models. Tables 69 and 70 shows the estimated labor costs per product to modify the “multi-factor authentication” (MFA) certification criterion in § 170.315(d)(13). 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 71.</P>
                    <P>2. We estimate that 323 products certified by 252 developers will be affected by our proposal. These estimates are a subset of the total estimated health IT developers and certified products we estimated above.</P>
                    <P>The estimate of 323 products certified by 252 developers is derived as follows. We estimate that, in total, 387 health IT developers will certify 521 health IT products impacted by this rulemaking. However, not all these developers and products will need to certify the revised § 170.315(d)(13) certification criterion and need to meet the proposed requirements. As of the end of 2022, 96% of developers and 96% of products certified § 170.315(d)(13). The proposed modification to the certification criterion revises the certification criteria that must comply with this certification criterion to § 170.315(e)(1), § 170.315(g)(10), and § 170.315(b)(3) alone. As of the end of 2022, 65% of developers and 62% of products certified § 170.315(e)(1), § 170.315(g)(10), or § 170.315(b)(3). We applied this modifier to our total developer and product estimate as an overall estimate of the number of developers and products impacted by and need to comply with the proposed modifications to the certification 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 $127.82.</P>
                    <GPH SPAN="3" DEEP="216">
                        <GID>EP05AU24.077</GID>
                    </GPH>
                    <GPH SPAN="3" DEEP="271">
                        <PRTPAGE P="63749"/>
                        <GID>EP05AU24.078</GID>
                    </GPH>
                    <GPH SPAN="3" DEEP="167">
                        <GID>EP05AU24.079</GID>
                    </GPH>
                    <P>The cost to a health IT developer to modify the “multi-factor authentication” certification criterion for their Health IT Modules would range from $0 to $36,407 per product, on average. Therefore, assuming 323 products overall and a labor rate of $127.82 per hour, we estimate that the total cost to all health IT developers would, on average, range from $0 to $11.8 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>The proposed updates will improve information security and access. We believe our proposal helps improve security by increasing support of MFA. This is because it is unlikely that an unauthorized individual or entity will be able to succeed in proving one's identity when more than one authentication factor is used. The MFA certification criterion, as adopted through the ONC Cures Act Final Rule, required an attestation to promote transparency and encourage health IT developers who were not using MFA to do so. In that rule we articulated expected benefits that adopting MFA would reduce the likelihood that authentication credentials would be compromised and would eliminate an unnecessary use of IT resources and could directly reduce providers' operating/support costs, which would reduce their administrative and financial burden.</P>
                    <P>
                        At the time, we believed supporting MFA to be an established best practice among industry developers, including health IT developers, but we did not have access to published literature that detailed how health IT developers were already supporting MFA industry-wide, but we believed the majority of health IT developers, or around 80%, were taking such actions. We assumed that building this functionality was in the future project plans for the remaining 20% because, as noted previously, adopting these capabilities is an industry best practice. We believed that health IT developers that had not yet adopted these capabilities were likely making financial investments to get up to speed with industry standards. We believed our proposal would motivate 
                        <PRTPAGE P="63750"/>
                        these health IT developers to speed their implementation process. We also did not attribute a monetary estimate to this potential benefit because our rule is not a direct cause of health IT developers adopting these capabilities.
                    </P>
                    <P>The Program data for MFA attestations tell us that less than half of developers attested “yes” that they support MFA, far less than the 80% we assumed support MFA in our prior rulemaking. The attestation alone does not confirm support of MFA, but the data does tell us the attestation alone may be insufficient to enforce this information security best practice across certified health IT. Ensuring Health IT Modules use industry best practice to protect health information will benefit the security of patient health information and prevent malicious access to authentication credentials. This proposed revision further motivates certified health IT developers to develop this information security for their products. The benefits of these modifications are not quantifiable at this time, and we welcome comment on how to quantify these benefits, if any.</P>
                    <HD SOURCE="HD3">18. Revised Computerized Provider Order Entry—Laboratory Criterion</HD>
                    <P>We propose to update the “computerized provider order entry—laboratory” certification criterion in § 170.315(a)(2) to require enabling a user to create and transmit laboratory orders electronically according to the standard specified in § 170.205(g)(2), the HL7® Laboratory Order Interface (LOI) Implementation Guide. We further propose to update § 170.315(a)(2) to require technology to receive and validate laboratory results according to the standard specific in § 170.205(g)(3), the HL7® Laboratory Results Interface (LRI) Implementation Guide. Ensuring that systems creating laboratory orders can transmit orders and receive associated results and values electronically, according to national standards, will create more complete patient information available to clinicians throughout the laboratory workflow.</P>
                    <HD SOURCE="HD3">Costs</HD>
                    <P>This section describes the estimated cost of meeting the requirements in the proposed updates to § 170.315(a)(2). These tasks have their own level of effort, and these estimates are detailed in Tables 72 and 73 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 72 shows the estimated labor costs per product to meet the proposed requirements in § 170.315(a)(2). 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 73.</P>
                    <P>2. We estimate that 302 products certified by 33 developers will be affected by our proposal. These estimates are a subset of the total estimated health IT developers and certified products we estimated above. The estimate of 302 products certified by 33 developers is derived as follows. We estimate that, in total, 387 health IT developers will certify 521 health IT products impacted by this rulemaking. However, not all these developers and products certify § 170.315(a)(2) and § 170.315(f)(3) (Transmission to public health agencies—reportable laboratory tests and values/results) need to meet the proposed requirements. As of the end of 2022, 62% of developers and 58% of products certified § 170.315(a)(2) and 10% of developers and 9% of products certified to § 170.315(f)(3). We applied these modifiers to our total developer and product estimate, after removing duplicates as an overall estimate of the number of developers and products impacted by the proposed modifications to the certification 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 $127.82.</P>
                    <GPH SPAN="3" DEEP="404">
                        <PRTPAGE P="63751"/>
                        <GID>EP05AU24.080</GID>
                    </GPH>
                    <GPH SPAN="3" DEEP="286">
                        <PRTPAGE P="63752"/>
                        <GID>EP05AU24.081</GID>
                    </GPH>
                    <P>The cost to products and developers to meet the proposed requirements in creating and transmitting laboratory orders according to § 170.205(g)(2) standard would range from $63,910 to $127,820 per product, on average. The products and developers to meet the proposed requirements in receive and validating the laboratory results according to § 170.205(g)(3) standard would also range from $63,910 to $127,820 per product. Therefore, assuming 302 products overall and a labor rate of $127.82 per hour, we estimate that the total cost to all health IT developers would, on average, range from $39 million to $77 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>We believe this proposal would benefit health care providers, patients, and the industry. The updates to these specifications, and the inclusion of the receipt of orders in § 170.315(f)(3), as well as the receipt of results in § 170.315(a)(2), ensure that functions throughout the lifecycle of the laboratory order, from entry, to result, to reporting to public health agency, is covered by electronic requirements with the associated national standard. We believe these proposed updates will enhance the completeness of critical patient information that are made available to clinicians, laboratory, and public health agency receiving the laboratory results. Addressing the current gaps in patient information is critical as we strive to improve health equity as well as contact tracing and patient outreach to slow down the spread of infectious diseases.</P>
                    <P>
                        A typical interface between a laboratory information system and electronic health record can cost between $5,000 to $50,000 and take up to six months to implement.
                        <SU>453</SU>
                        <FTREF/>
                         The expense and complexity of these interfaces and implementation efforts are primarily due to a lack of consistent application of industry standards for laboratory result reporting. The LOI and LRI Implementation Guides address variability and customization that was possible in Electronic Laboratory Reporting (ELR) by providing an unambiguous specification for ambulatory lab reporting, significantly decreasing the need for mapping or unique configuration for each interface. These implementation guides also have uses beyond public health reporting where hospitals and other users could re-use existing orders and results interfaces used for non-public health purposes for public health purposes instead of needing to implement a new specification.
                    </P>
                    <FTNT>
                        <P>
                            <SU>453</SU>
                             
                            <E T="03">https://www.politico.com/story/2015/02/data-fees-health-care-reform-115402.</E>
                        </P>
                    </FTNT>
                    <P>The LRI IG outlines multiple use cases, allowing for flexibility and scalability while reducing implementation and maintenance burden for the users. It also includes details such as formatting time stamp that will help reduce the need for standardization afterwards. The LOI IG has the potential to support inter-organizational care, improve care delivery, and clinical outcomes.</P>
                    <P>Although the benefits of these modifications are not quantifiable at this time, we expect the resulting improvements to interoperable exchange of health information to significantly benefit health care providers, laboratories, and public health agencies and improve the quality of health care provided. Public health initiatives will benefit from the proposed changes through increased standardization and interoperability of laboratory computerized provider order entry.</P>
                    <HD SOURCE="HD3">19. Revised Standardized API for Patient and Population Services Criterion To Align With Modular API Capabilities</HD>
                    <P>
                        As part of our overall proposal, we propose to revise the structure of the regulation text in § 170.315(g)(10) for clarity as well as phrasing consistency with other proposed API certification criteria in this proposed rule (
                        <E T="03">e.g.,</E>
                         the proposed applicable § 170.315(j) certification criteria). We do not believe 
                        <PRTPAGE P="63753"/>
                        this revision will create additional development effort as many of the functional requirements for Health IT Modules remain the same. We request comment on additional burden and level of effort for the proposed revisions.
                    </P>
                    <P>We, however, propose new functional requirements for § 170.315(g)(10) beyond these revisions to regulation text and describe them and their estimated burden, below:</P>
                    <HD SOURCE="HD3">Patient and User Authorization Revocation</HD>
                    <P>This would require a Health IT Module's authorization server to be able to revoke and must revoke an authorized application's access at a user's direction within 1 hour of the request. This is distinct from the existing patient authorization revocation requirement currently in § 170.315(g)(10)(vi) which requires support for revocation of a patient's authorization but does not require support for revocation of a clinician's authorization. We propose introducing this requirement to support revocation for both patient and clinician authorizations to enable clinicians to have greater control over their authorizations for applications to access patient data. We believe the underlying functionality to support user authorization revocation is very similar to the current adopted functionality of patient access revocation, and do not estimate additional burden to support both revocation functionalities. We request comment on additional burden to support this revocation functionality.</P>
                    <HD SOURCE="HD3">Alignment With Proposed (j) Certification Criteria (1)-(7)</HD>
                    <P>We propose to add a new category of certification criteria to § 170.315(j) titled “Modular API capabilities.” The § 170.315(j) certification criteria, if finalized, would allow for specific API certification requirements to be demonstrated independently or in different combinations through the Program (when meeting all of § 170.315(g)(10)'s requirements would not be applicable). Technology updates to the Standardized API certification criterion are considered to be minimal, as the applicable new (j) certification criteria are already supported by Health IT Modules certified to the certification criterion and believe they would not require additional development effort. We request comment on additional burden to support alignment of the certification criterion with the proposed certification criteria § 170.315(j)(1) through § 170.315(j)(7).</P>
                    <HD SOURCE="HD3">Support for Workflow Triggers for Decision Support Interventions</HD>
                    <P>We propose to require support for workflow triggers for decision support interventions under proposed § 170.315(g)(10)(iv). We propose that the Health IT Module must support capabilities in § 170.315(j)(20) (where we have proposed to adopt the “workflow triggers for decision support interventions” certification criterion) to enable workflow triggers to call decision support services, including support for “patient-view” and “order-sign” CDS Hooks according to at least one of the versions of the implementation specification adopted in § 170.215(f)(1).</P>
                    <HD SOURCE="HD3">Support for Verifiable Health Records (j)(22)</HD>
                    <P>We propose support for the issuance of verifiable health records as specified by the requirements in proposed § 170.315(j)(22) be supported. We propose requiring support for verifiable health records in the § 170.315(g)(10) certification criterion to support the ability for patients to access their immunization and infectious disease-related laboratory test information in a format that is easily portable and verifiable by third parties.</P>
                    <HD SOURCE="HD3">Costs</HD>
                    <P>The tasks and estimated cost to revise § 170.315(g)(10) to support verifiable health records are detailed in Tables 74 to 75 below and are based on the following assumptions:</P>
                    <P>1. Health IT developers will use the same labor costs and data models. Table 74 shows the estimated labor costs per product to revise § 170.315(g)(10) to support verifiable health records. 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 75.</P>
                    <P>2. We estimate that 224 products certified by 182 developers will be affected by our proposal. These estimates are a subset of the total estimated number of health IT developers and certified products we estimated above. The estimate of 224 products certified by 182 developers is derived as follows. We estimate that, in total, 387 health IT developers will certify 521 health IT products impacted by this rulemaking. However, not all these developers and products certify to the § 170.315(g)(10) certification criterion and need to meet the proposed requirements. As of the end of 2022, 47% of developers and 43% of products certified to § 170.315(g)(10) certification criterion. We applied this modifier to our total developer and product estimate as an overall estimate of the number of developers and products impacted by the proposed modifications to the certification 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 $127.82.
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>454</SU>
                             Estimate derived from a prototype implementation of SMART on FHIR, in which four EHR vendors completed necessary work with one or two software engineers in under 2 months without previously implementing any portion of the FHIR API. Source: SMART on FHIR: a standards-based, interoperable apps platform for electronic health records—PMC (
                            <E T="03">nih.gov</E>
                            ).
                        </P>
                        <P>
                            <SU>455</SU>
                             Please reference the impact analysis for verifiable health records for more information about the costs and benefits of adopting the SMART Health Cards standard.
                        </P>
                    </FTNT>
                    <BILCOD>BILLING CODE 4150-45-P</BILCOD>
                    <GPH SPAN="3" DEEP="564">
                        <PRTPAGE P="63754"/>
                        <GID>EP05AU24.082</GID>
                    </GPH>
                    <BILCOD>BILLING CODE 4150-45-C</BILCOD>
                    <GPH SPAN="3" DEEP="244">
                        <PRTPAGE P="63755"/>
                        <GID>EP05AU24.083</GID>
                    </GPH>
                    <P>The cost to meet the proposed requirements to revise the “standardized API for patient and population services” certification criterion to support verifiable health records would range from $0 to $230,076 per product, on average. Therefore, assuming 224 products overall and a labor rate of $127.82 per hour, we estimate that the total cost to all health IT developers would, on average, range from $0 to $51.5 million.</P>
                    <HD SOURCE="HD3">Benefits</HD>
                    <P>
                        Requiring Health IT Modules to enable patient access to immunization information stored in certified health IT using SMART Health Cards in § 170.315(j)(22) provides several benefits to both patients and providers. SMART Health Cards provide an easy way to store vaccination history and test results for personal records and enable patients to easily share their status with an organization when needed. SMART Health Cards empower patients by providing secure access to their electronic health information.
                        <SU>456</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>456</SU>
                             Smart-Cards-in-Healthcare-FAQ-Series-Smart-Cards-and-Patients.pdf (
                            <E T="03">securetechalliance.org</E>
                            ).
                        </P>
                    </FTNT>
                    <P>
                        The SMART Health Card framework has been used, for example, to deploy Digital Vaccine Records (DVR) for vaccine verification which contain name, date of birth, vaccination dates, and vaccine manufacturer, much like the COVID-19 vaccination paper card.
                        <SU>457</SU>
                        <FTREF/>
                         This makes it more convenient for individuals to show proof of vaccination by downloading their DVR rather than maintaining a paper card. In August of 2021, the California Department of Public Health required all hospital visitors to show proof of vaccination or a negative test result within 72 hours. Two physicians/clinical informatics scholars from University of California San Diego shared their experience that hospital visitors expressed their appreciation for the ease and accessibility of the digital cards, especially if they did not have their paper vaccine cards. The digital cards also made the validation process easier for staff who were checking vaccination status. Thus, SMART Health Cards also have several benefits to hospitals and health care providers. For instance, SMART Health Cards enable accurate identification of patients who receive care, can help expedite admissions processes, decrease medical errors, and reduce healthcare costs.
                        <SU>458</SU>
                        <FTREF/>
                         Further, enabling patient access to SMART Health Cards would increase patient access to electronic health information, which enables individuals to make more informed decisions about their health and care.
                    </P>
                    <FTNT>
                        <P>
                            <SU>457</SU>
                             
                            <E T="03">https://www.mcpdigitalhealth.org/article/S2949-7612(23)00008-1/fulltext.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>458</SU>
                             Smart-Cards-in-Healthcare-FAQ-Series-Smart-Cards-and-Healthcare-Providers.pdf (
                            <E T="03">securetechalliance.org</E>
                            ).
                        </P>
                    </FTNT>
                    <P>Clinicians will benefit from the updates to the certified criterion through increased standardization and interoperability of CDS Hooks technology. Certified use of CDS Hooks is expected to facilitate more patient-specific results from clinical decision support tools, assisting providers in a more patient-centric approach to care. Based on public feedback on ONC's request for information in the HTI-1 Proposed Rule, commenters were generally more supportive of certification criteria for adoption of the v2.0 specification of FHIR CDS Hooks, as opposed to v1.0. Many also preferred ONC supporting narrow certification criteria related to a particular user guide, as we have specified in this proposal. Further, we believe that the “patient-view” and “order-sign” hooks proposed to be required for certification are the most mature, as supported by public comment, and that current implementers of CDS Hooks will be able to implement this with limited additional challenge. We believe the nature of our proposal addresses some of these concerns. Further, the “patient-view” and “order-sign” hooks were among the hooks recommended by commenters to use as part of the certification requirements. Given commenter concerns for use-case specific guidance, we propose support for the “patient-view” and “order-sign” hooks, specifically, given their broad applicability across use cases.</P>
                    <HD SOURCE="HD3">Support for Subscriptions—Server (j)(23)</HD>
                    <P>
                        We propose support for subscriptions as a server according to the requirements specified in § 170.315(j)(23). This is to support the distinct proposal for subscriptions for public health use cases as proposed in this rule at section titled “Health IT Modules Supporting Public Health Data Exchange.” We believe, as noted in the impact analysis for the “Standardized 
                        <PRTPAGE P="63756"/>
                        API for Public Health Data Exchange” certification criterion in § 170.315(g)(20), that Health IT Modules that will need to adopt the new § 170.315(g)(20) certification criterion already supports the § 170.315(g)(10) certification criterion. And, as we propose that § 170.315(g)(20) support the proposed § 170.315(j)(23) certification criterion, revisions to § 170.315(g)(10) to support § 170.315(j)(23) should be minimal, as support for § 170.315(j)(23) should already be built into updates for these Health IT Modules. We request comment on additional burden to support this functionality.
                    </P>
                    <HD SOURCE="HD3">20. Patient, Provider, and Payer APIs</HD>
                    <P>We have proposed a set of certification criteria for payer data exchange, beneficiary access, and network information APIs in § 170.315(g)(30) through (36) that aim to complement and advance the policies that CMS has developed to increase patient, provider, and payer access to information. If health IT developers (including those that support payers or are part of a payer) were to seek testing and certification to these proposed certification criteria, we believe that they would be better positioned to support more effective exchange of clinical, coverage, and prior authorization information and would help ensure that technology used to satisfy the CMS requirements has been tested for conformance with widely available industry standards designed to support interoperability for each use case. These proposed certification criteria reference a set of API implementation specifications based upon the HL7® FHIR® Release 4 base standard. The new certification criteria also incorporate FHIR capabilities proposed in § 170.315(j), which are proposed elsewhere in this rule. These certification criteria include FHIR capabilities such as CDS Hooks and requirements for authorization and authentication, among others.</P>
                    <P>The proposed certification criteria would enable users of certified health IT to meet requirements for payers and providers in the CMS regulations, specifically, CMS API requirements at the following: Patient Access API (85 FR 25558), Provider Access API (87 FR 76254), Payer-to-Payer API (87 FR 76243), Prior Authorization and Requirements Discovery (PARDD) API (87 FR 76285), and the Provider Directory API (85 FR 25559). We propose to adopt and reference the same required and recommended implementation specifications within the certification criteria.</P>
                    <HD SOURCE="HD3">Costs</HD>
                    <P>The proposed certification criteria are:</P>
                    <FP SOURCE="FP-1">• § 170.315(g)(30) Beneficiary access</FP>
                    <FP SOURCE="FP-1">• § 170.315(g)(31) Payer to provider exchange (provider)</FP>
                    <FP SOURCE="FP-1">• § 170.315(g)(32) Payer to provider exchange (payer)</FP>
                    <FP SOURCE="FP-1">• § 170.315(g)(33) Payer to payer exchange</FP>
                    <FP SOURCE="FP-1">• § 170.315(g)(34) Prior authorization (provider)</FP>
                    <FP SOURCE="FP-1">• § 170.315(g)(35) Prior authorization (payer)</FP>
                    <FP SOURCE="FP-1">• § 170.315(g)(36) Network information</FP>
                    <P>Certification criteria (g)(30), (g)(32), (g)(33), (g)(35), and (g)(36) adopt and reference the same required and recommended implementation specifications from the CMS requirements. For the purposes of this impact analysis, we assume that health IT developers (including those that support payers or are part of a payer) who elect to test and certify their Health IT Modules to any one of these four certification criteria face no additional costs beyond those estimated in the CMS regulatory impact analysis for these API requirements. We assume the same level of effort estimated by CMS. Furthermore, the certification criteria provide a predictable and transparent method of health IT developers to test and certify that their modules meet the CMS API requirements, providing entities required to meet these API requirements a way to demonstrate conformance to their users.</P>
                    <P>Certification criteria (g)(31) and (g)(34) enable bi-directional exchange and transfer of data between payer systems (who must meet CMS API requirements) and provider systems who receive information from payer systems to inform patient care and facilitate prior authorization. These two certification criteria do not implement CMS requirements (which only affect payer systems), but if adopted by health IT developers can further enable interoperability between payer and provider systems. The effort to test and certify these two certification criteria goes beyond the requirements to meet CMS API requirements, however, no policy in this proposed rule requires adoption of these certification criteria. We see these as optional certification criteria that may be voluntarily adopted by health IT developers to further interoperability. The impact analysis, below, estimates costs for a single Health IT Module to adopt the certification criteria: “Payer to provider exchange (provider)” and “Prior authorization (provider)”. The impact analysis assumes no additional costs for health IT developers to adopt “Beneficiary Patient access”, “Payer to provider exchange (payer)”, “Payer to payer exchange”, “Prior authorization (payer)”, and “Network information”.</P>
                    <P>The proposed certification criteria: “Payer to provider exchange (provider)” and “Prior authorization (provider)” have their own level of effort and these estimates are detailed in Tables 76 to 79 below and are based on the following assumptions:</P>
                    <P>Health IT developers will use the same labor costs and data models. Tables 76 and 77 shows the estimated labor costs per product to develop “Payer to provider exchange (provider)” and “Prior authorization (provider)”. 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 Tables 78 and 79.</P>
                    <P>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 $127.82.</P>
                    <BILCOD>BILLING CODE 4150-45-P</BILCOD>
                    <GPH SPAN="3" DEEP="423">
                        <PRTPAGE P="63757"/>
                        <GID>EP05AU24.084</GID>
                    </GPH>
                    <GPH SPAN="3" DEEP="640">
                        <PRTPAGE P="63758"/>
                        <GID>EP05AU24.085</GID>
                    </GPH>
                    <BILCOD>BILLING CODE 4150-45-C</BILCOD>
                    <GPH SPAN="3" DEEP="139">
                        <PRTPAGE P="63759"/>
                        <GID>EP05AU24.086</GID>
                    </GPH>
                    <GPH SPAN="3" DEEP="182">
                        <GID>EP05AU24.087</GID>
                    </GPH>
                    <P>The cost to a health IT developer to develop criteria “payer to provider exchange (provider)” and “prior authorization (provider)” for their Health IT Modules would range from $323,000 to $936,000 per product, on average. Individually, the cost to develop “payer to provider exchange (provider)” would be $73,500 to $294,000 per product and “prior authorization (provider)” would be $249,000 to $642,000 per product.</P>
                    <HD SOURCE="HD3">Benefits</HD>
                    <P>
                        Payers and providers have both adopted electronic prior authorization and it has increased from 12% to 28% from 2018 to 2022.
                        <SU>459</SU>
                        <FTREF/>
                         Phone and fax is largely used by payers to manage prior authorizations and the peer-to-peer review process for denial appeals.
                        <SU>460</SU>
                        <FTREF/>
                         Prior authorization poses a large financial and administrative burden on clinicians prescribing medication.
                        <SU>461</SU>
                        <FTREF/>
                         A recent survey found that physicians spent 1 hour per week on average, nursing staff spent about 13 hours per week on average, and clerical staff spent about 6 hours per week on average completing prior authorization activities.
                        <SU>462</SU>
                        <FTREF/>
                         Another survey found that individual manual prior authorization took about 20 minutes, portal prior authorization took 12 minutes, and electronic prior authorization took 9 minutes. Another survey which had 1,147 responses from 100,000 providers found that most providers spent up to 5 hours per week on prior authorization submissions. There was no difference in the amount of time it took to complete manual prior authorizations compared to electronic prior authorizations.
                        <SU>463</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>459</SU>
                             
                            <E T="03">https://www.caqh.org/sites/default/files/2022-caqh-index-report%20FINAL%20SPREAD%20VERSION.pdf.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>460</SU>
                             
                            <E T="03">https://ascopubs.org/doi/full/10.1200/EDBK_100036.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>461</SU>
                             
                            <E T="03">https://www.sciencedirect.com/science/article/pii/S1551741118301542?via%3Dihub.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>462</SU>
                             
                            <E T="03">https://onlinelibrary.wiley.com/doi/full/10.1111/ctr.14964.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>463</SU>
                             
                            <E T="03">https://www.ncbi.nlm.nih.gov/pmc/articles/PMC10332446/.</E>
                        </P>
                    </FTNT>
                    <P>
                        Prior authorization decisions can cause patient distress, make untreated symptoms last longer, and delay diagnosis. In 2020, the CAQH estimated that the cost to providers of a manual prior authorization approval was $10.92 per claim, while the cost to payers was $3.32 per claim. In 2018, the Cleveland Clinic estimated the cost to providers was $12 per claim. A policy paper for The Hamilton Project calculated that staff time is approximately 25 hours per week in resolving 37 prior authorization adjudications at $20 per hour, which equals $14 per claim as a cost to medical staff.
                        <SU>464</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>464</SU>
                             
                            <E T="03">https://www.hamiltonproject.org/wp-content/uploads/2023/01/Cutler_PP_LO.pdf.</E>
                        </P>
                    </FTNT>
                    <P>
                        One possible benefit to standardization of prior authorization is a shorter decision time on prior authorizations. Based on a survey of 1,147 responses from 100,000 providers, physicians and researchers from University of Nebraska Medical Center found it took health plans less time to submit decisions electronically, though providers had similar challenges with electronic prior authorizations as they did with manual prior authorizations.
                        <SU>465</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>465</SU>
                             
                            <E T="03">https://www.ncbi.nlm.nih.gov/pmc/articles/PMC10332446/.</E>
                        </P>
                    </FTNT>
                    <P>
                        There are several pilots underway to test the prior authorization API, as well as other tools. One pilot, led by Regence, used the HL7 FHIR standard to automate prior authorization. Using the SmartAuth app integrated with the Epic EHR, they were able to automatically populate policy criteria and automatically extract clinicals from the EHR. They were able to make immediate 
                        <PRTPAGE P="63760"/>
                        determinations on over 90% of the requests with nearly all determined that prior authorization was not required. Whereas, without the use of the app and automated process, providers might wait hours or days just to find out prior authorization is not required. In some cases, prior authorization was automatically processed, enabling an immediate decision to prescribe or suggest a treatment. This was all enabled using an API built using the FHIR standard.
                    </P>
                    <P>Setting a standard, electronic method to facilitate payer and provider exchange and the prior authorization of certain treatments and medications can reduce overall time and effort for payers and providers alike. A standard, uniform process can also be replicated across many IT systems, ensuring reliable interoperability between systems and more certainty to providers that they can electronically submit a prior authorization to a payer and receive a response congruent with their technology and workflow. A piecemeal system where providers may need to follow different procedures and processes for different payers increases burden on providers and administrators and reduces their time to treat and manage patients.</P>
                    <P>
                        CMS in their final rule, “Medicare and Medicaid Programs; Patient Protection and Affordable Care Act; Advancing Interoperability and Improving Prior Authorization Processes for Medicare Advantage Organizations, Medicaid Managed Care Plans, State Medicaid Agencies, Children's Health Insurance Program (CHIP) Agencies and CHIP Managed Care Entities, Issuers of Qualified Health Plans on the Federally-Facilitated Exchanges, Merit-Based Incentive Payment System (MIPS) Eligible Clinicians, and Eligible Hospitals and Critical Access Hospitals in the Medicare Promoting Interoperability Program”, assessed the overall benefit and level of effort to standardize prior authorization and payer exchange.
                        <SU>466</SU>
                        <FTREF/>
                         CMS estimates, over a ten-year period, that physician groups and hospitals could face reduced costs of $15.3 billion if they adopted this technology to standardize prior authorization. We believe that these proposed certification criteria would provide a reliable and transparent testing and certification process for the functionalities proposed by CMS to facilitate data exchange and prior authorization, helping to enable these expected benefits for technology users. As stated earlier, these proposed certification criteria adopt the standards and functionality proposed by CMS and we assume that testing and certifying these certification criteria would not exceed the level effort estimated by CMS. We also believe that these certification criteria, if voluntarily adopted by developers, would help ensure that the technology are developed and deployed in a standard, uniform way, culminating into the expected savings to physician groups and hospitals estimated by CMS in their rulemaking.
                    </P>
                    <FTNT>
                        <P>
                            <SU>466</SU>
                             
                            <E T="03">https://www.federalregister.gov/documents/2024/02/08/2024-00895/medicare-and-medicaid-programs-patient-protection-and-affordable-care-act-advancing-interoperability.</E>
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">21. Insights</HD>
                    <P>
                        We propose to update the Insights condition of certification to incorporate updates and revisions based on proposed changes to certification requirements in this proposed rulemaking that affect the Insights measures finalized in HTI-1. The proposed updates to the Insights condition of certification include: (1) updates to the “Individuals' access to electronic health information through certified health IT” Insights measure; (2) updates to the “C-CDA medications, allergies, and problems reconciliation and incorporation through certified health IT” Insights measure; and (3) new requirements for developers of certified health IT to list the clients and their publicly available identifiers (
                        <E T="03">e.g.,</E>
                         NPI) who were included in the measurement of submitted Insights measures.
                    </P>
                    <HD SOURCE="HD2">Estimated Labor Hours To Meet Updated “Individuals' Access to Electronic Health Information Through Certified Health IT” Measure for Insights</HD>
                    <P>
                        In the HTI-1 Final Rule, the “Individuals' access to electronic health information through certified health IT” measure and related metrics only counts individuals' access of their EHI when measuring access to EHI.
                        <SU>467</SU>
                        <FTREF/>
                         We request comment on whether the changes proposed related to revising the definition of counting access to EHI to include both individuals and individuals' authorized representatives accessing their EHI (rather than just individuals alone) would have an incremental increase (or decrease) in burden compared to what was estimated in the HTI-1 Final Rule. The HTI-1 Final Rule regulatory impact analysis found that it would cost between $170,000 and $354,000 per developer to implement this measure.
                    </P>
                    <FTNT>
                        <P>
                            <SU>467</SU>
                             
                            <E T="03">https://www.federalregister.gov/documents/2024/01/09/2023-28857/health-data-technology-and-interoperability-certification-program-updates-algorithm-transparency-and.</E>
                        </P>
                    </FTNT>
                    <P>We believe it would be beneficial to developers of certified health IT to make ONC's patient access measure consist with the CMS Promoting Interoperability (PI) Measure for patient access (“Provide Patients Electronic Access to Their Health Information”), which counts both patients and their authorized representatives for measuring patient access for access using portals or apps.</P>
                    <P>We expect that the proposed changes would not impact or potentially reduce burden associated with implementing this measure as previously estimated in the HTI-1 Final Rule as it now aligns with how CMS operationalizes this measure; however, we request comment on this.</P>
                    <HD SOURCE="HD2">Estimated Labor Hours To Meet Updated “C-CDA Reconciliation and Incorporation Through Certified Health IT” Measure for Insights</HD>
                    <P>
                        The “C-CDA medications, allergies, and problems reconciliation and incorporation through certified health IT” measure was finalized in the HTI-1 Final Rule and is now proposed to be renamed as “C-CDA reconciliation and incorporation through certified health IT”.
                        <SU>468</SU>
                        <FTREF/>
                         The prior HTI-1 Final Rule regulatory impact analysis found that it would cost between $402,000 and $1,117,000 per developer to implement this measure.
                    </P>
                    <FTNT>
                        <P>
                            <SU>468</SU>
                             
                            <E T="03">https://www.federalregister.gov/documents/2024/01/09/2023-28857/health-data-technology-and-interoperability-certification-program-updates-algorithm-transparency-and.</E>
                        </P>
                    </FTNT>
                    <P>We request comment on the incremental burden associated with updating the measure to align with updates to the certification criterion § 170.315(b)(2). Specifically, we are requesting comment on the potential increase in burden associated with updating the metric to include additional data classes that are proposed (in one proposal 6 data classes, in another proposal all data classes associated with USCDI v4). We are also requesting comment on the additional incremental costs associated with dividing the metrics according to the use of the three processes that make up the definition for “any method” so that it aligns with the updates being proposed to § 170.315(b)(2) related to automatic reconciliation and incorporation capabilities.</P>
                    <HD SOURCE="HD3">Estimated Labor Hours To Meet Provider Listing Requirements for Insights</HD>
                    <P>
                        The Insights condition of certification, as finalized in the HTI-1 Final Rule, 
                        <PRTPAGE P="63761"/>
                        allows developers of certified health IT to select specific end-users to submit data for measurement of applicable Insights measures, due to known constraints with developers' ability to get data needed to inform Insights measures from their clients' systems. ONC granted flexibility to developers in how they calculate their measures, given this reality. We propose to update the Insights condition to include an additional requirement for developers who submit any Insights measure to include a list of the clients included in the measurement of the submitted measure(s). This will enable further analysis of the measures to determine representativeness of clients included in measurements.
                    </P>
                    <HD SOURCE="HD3">Costs</HD>
                    <P>The tasks associated with proposed requirement to provide client information have their own level of effort and these estimates are detailed in Tables 80 and 81 below and are based on the following assumptions:</P>
                    <P>1. Health IT developers will use the same labor costs and data models. Table 80 shows the estimated labor costs per product to modify their technology to collect the requested or measures. 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 81.</P>
                    <P>2. We estimate that 176 products certified by 59 developers will be affected by our proposal. These estimates are a subset of the total estimated health IT developers and certified products we estimated above.</P>
                    <P>The estimate of 176 products certified by 59 developers is derived as follows. We estimate that, in total, 387 health IT developers will certify 521 health IT products impacted by this rulemaking. However, not all these developers and products must meet the Insights condition of certification and need to meet the proposed requirements. In the HTI-1 Final Rule we estimated the number of developers and products that would be required to meet the Insights condition of certification, based on thresholds designed to capture insightful measures from the developers of certified health IT with the largest market share, excluding developers who server fewer than 50 hospitals or 500 clinicians and who certify a criterion with an applicable Insights measure.</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 $127.82.</P>
                    <BILCOD>BILLING CODE 4150-45-P</BILCOD>
                    <GPH SPAN="3" DEEP="617">
                        <PRTPAGE P="63762"/>
                        <GID>EP05AU24.088</GID>
                    </GPH>
                    <GPH SPAN="3" DEEP="278">
                        <PRTPAGE P="63763"/>
                        <GID>EP05AU24.089</GID>
                    </GPH>
                    <GPH SPAN="3" DEEP="153">
                        <GID>EP05AU24.090</GID>
                    </GPH>
                    <BILCOD>BILLING CODE 4150-45-C</BILCOD>
                    <P>The cost to a health IT developer to meet the proposed Insights requirements for their Health IT Modules would range from $6,647 to $39,369 per developer, on average. Therefore, assuming 59 developers overall and a labor rate of $127.82 per hour, we estimate that the total cost to all health IT developers would, on average, range from $392,00 to $2.3 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>The proposed update to the Insights Condition of Certification will enable more granular analysis and utility of the submitted Insights measures. The additional data will enable richer comparisons of measures across developers, creating greater value from the measures. The level of effort is low and could be programmed for successive reporting years.</P>
                    <HD SOURCE="HD3">
                        22. Trusted Exchange Framework and Common Agreement
                        <SU>SM</SU>
                    </HD>
                    <P>
                        This regulation does not establish the requirements for the Trusted Exchange Framework and Common Agreement
                        <SU>SM</SU>
                         (TEFCA
                        <SU>SM</SU>
                        ), but instead outlines the application requirements an Applicant QHIN must submit in order to be Designated as a QHIN, and the requirements that an entity would attest to meeting as a participant in the TEFCA networks. We estimate that an Applicant QHIN would spend on average an hour to complete the application process. We estimate that an average Qualified Health Information Network
                        <SU>TM</SU>
                         (QHIN
                        <SU>TM</SU>
                        ) would spend at most one hour to complete the attestation process. We consider the effort to be de minimis.
                    </P>
                    <P>
                        We do not assess the burden of a QHIN to appeal a Recognized Coordinating Entity® (RCE
                        <SU>TM</SU>
                        ) decision as part of their participation in the TEFCA networks, as this proposed rulemaking creates the appeals process for QHINs but does not require it. Furthermore, appeals follow RCE decisions related to QHIN participation in the TEFCA networks, not ONC decisions. We, therefore, do not assess the burden of the appeals process as part of this proposed rulemaking's impact analysis.
                        <PRTPAGE P="63764"/>
                    </P>
                    <HD SOURCE="HD3">Total Annual Cost Estimate</HD>
                    <P>We estimate that the total annual cost for this proposed rule for the first year after it is finalized (including one-time costs), based on the cost estimates outlined above and throughout this RIA, would result in $431.1 million. The total undiscounted perpetual cost over a 10-year period for this proposed rule (starting in year two), based on the cost estimates outlined above, would result in $398.1 million. We estimate the total costs to health IT developers to be $829.2 million.</P>
                    <P>We assume costs to health IT developers will stagger based on the timeline for developers to meet specific requirements. All requirements are expected to be met by the end of the third year after the rule is final, so all estimated costs will be incurred within that timeframe. Because many of the new requirements will necessitate immediate work to begin developing new technology, we estimate that 50% of total costs will come in the first year the rule is finalized. We estimate that the remaining 50% of total costs will come in the second and third year after the rule is finalized. Most of the new requirements must be met at the end of the second year after the rule is finalized and so a larger portion of the remaining costs are estimated for Year 2, while fewer requirements must be met in the third year after the rule is finalized. This cost breakdown is shown in Table 83.</P>
                    <HD SOURCE="HD3">Total Annual Benefit Estimate</HD>
                    <P>We estimate the total annual benefit across all entities for this proposed rule beginning in Year 3, when the associated policies are required to be implemented and expected benefits to be realized, would be on average $22.2 million. We estimate the total benefits across all entities to be $177.6 million. This breakdown is shown in Table 83.</P>
                    <HD SOURCE="HD3">Total Annual Net Benefit</HD>
                    <P>We estimate the total undiscounted perpetual annual net benefit for this proposed rule (starting in year three), based on the estimates outlined above, would result in a net benefit of $75.4 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 proposed rule. Monetary annual effects are presented as discounted flows using 3% and 7% factors in Table 82 below. We are not able to explicitly define the universe of all costs but have provided an average of likely costs of this proposed rule as well as a high and low range of likely costs.</P>
                    <GPH SPAN="3" DEEP="299">
                        <GID>EP05AU24.091</GID>
                    </GPH>
                    <GPH SPAN="3" DEEP="226">
                        <PRTPAGE P="63765"/>
                        <GID>EP05AU24.092</GID>
                    </GPH>
                    <HD SOURCE="HD2">D. Regulatory Flexibility Act</HD>
                    <P>
                        The Regulatory Flexibility Act (RFA) requires agencies to analyze options for regulatory relief of small businesses if a rule has a significant impact on a substantial number of small entities. The Small Business Administration (SBA) establishes the size of small businesses for Federal Government programs based on average annual receipts or the average employment of a firm.
                        <SU>469</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>469</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>The entities that are likely to be directly affected by the requirements in this proposed rule requirements are health IT developers. We note that the proposed updates and clarifications to the reasonable and necessary activities that do not constitute information blocking would 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 refer readers to section IV for our information blocking-related proposals and welcome comments on their impacts on small entities.</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 proposed in this proposed rule most likely fall under the North American Industry Classification System (NAICS) code 541511 “Custom Computer Programming Services.” 
                        <SU>470</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>470</SU>
                             
                            <E T="03">https://www.sba.gov/sites/sbagov/files/2023-06/TableofSizeStandards_EffectiveMarch17-29,2023pdf.</E>
                        </P>
                    </FTNT>
                    <P>
                        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>471</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>471</SU>
                             
                            <E T="03">https://www.sba.gov/article/2022/feb/01/guidance-using-naics-2022-procurement.</E>
                        </P>
                    </FTNT>
                    <P>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>
                    <P>We estimate that the proposed requirements in this proposed rule would have effects on health IT developers, some of which may be small entities, that have certified health IT or are likely to pursue certification of their health IT under the Program. We believe, however, that we have proposed the minimum 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 proposed rule because at least a few of the proposals are derived directly from legislative mandates in the Cures Act.</P>
                    <P>We do not believe that the proposed requirements of this proposed rule would create a significant impact on a substantial number of small entities, but request comment on whether there are small entities that we have not identified that may be affected in a significant way by this proposed rule. Additionally, the Secretary proposes to certify that this proposed rule would not have a significant impact on a substantial number of small entities.</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 proposed rule (and subsequent final rule) that imposes substantial direct requirement costs on State and local governments, preempts State law, or otherwise has federalism implications. Nothing in this proposed rule imposes substantial direct compliance costs on State and local governments, preempts State law, or otherwise has federalism 
                        <PRTPAGE P="63766"/>
                        implications. We are not aware of any State laws or regulations that are contradicted or impeded by any of the proposals in this proposed rule. We welcome comments on this assessment.
                    </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 $183 million in 2024. While the estimated potential cost effects of this proposed rule reach the statutory threshold, we do not believe this proposed rule imposes unfunded mandates on State, local, and Tribal governments, or the private sector. We welcome comments on these conclusions.</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 record keeping requirements, Public health, Security.</P>
                        <CFR>45 CFR Part 172</CFR>
                        <P>Computer technology, Electronic health record, Electronic information system, Electronic transactions, Health, Healthcare, Health information technology, Health insurance, Health records, Hospitals, Laboratories, Medicaid, Medicare, Privacy, Public health, Security.</P>
                    </LSTSUB>
                    <P>For the reasons set forth in the preamble, HHS proposes to amend 45 CFR subtitle A, subchapter D, 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>
                    <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>
                    <AMDPAR>2. Revise § 170.101 to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 170.101</SECTNO>
                        <SUBJECT>Applicability.</SUBJECT>
                        <P>(a) The standards, implementation specifications, and certification criteria adopted in this part apply to health information technology and the testing and certification of Health IT Modules.</P>
                        <P>(b) If any provision of this part is held to be invalid or unenforceable facially, or as applied to any person, plaintiff, or circumstance, it shall be construed to give maximum effect to the provision permitted by law, unless such holding shall be one of utter invalidity or unenforceability, in which case the provision shall be severable from this part and shall not affect the remainder thereof or the application of the provision to other persons not similarly situated or to other dissimilar circumstances.</P>
                    </SECTION>
                    <AMDPAR>3. Amend § 170.102 by:</AMDPAR>
                    <AMDPAR>a. Revising and republishing the definition of “Base EHR”; and</AMDPAR>
                    <AMDPAR>b. Adding definitions for “Business day or Business days”, “Imaging link”, and “Serious risk to public health or safety” in alphabetical order.</AMDPAR>
                    <P>The revisions, additions, and republications read as follows:</P>
                    <SECTION>
                        <SECTNO>§ 170.102</SECTNO>
                        <SUBJECT>Definitions.</SUBJECT>
                        <STARS/>
                        <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>
                        <P>(iv) Section 170.315(b)(3) and 170.315(b)(4) on and after January 1, 2028;</P>
                        <P>(v) Section 170.315(g)(20) on and after January 1, 2028;</P>
                        <P>(vi) Section 170.315(g)(31) on and after January 1, 2028; and</P>
                        <P>(vii) Section 170.315(g)(34) on and after January 1, 2027.</P>
                        <P>
                            <E T="03">Business day</E>
                             or 
                            <E T="03">Business days</E>
                             means Monday through Friday, except the legal public holidays specified in 5 U.S.C. 6103 and any day declared to be a holiday by Federal statute or Executive order.
                        </P>
                        <STARS/>
                        <P>
                            <E T="03">Imaging link</E>
                             means technical details which enable the electronic viewing or retrieval of one or more images over a network.
                        </P>
                        <STARS/>
                        <P>
                            <E T="03">Serious risk to public health or safety</E>
                             means a single event or phenomenon or a recurring series of events or phenomena that by the nature and the fact of its occurrence endangers the life or safety of one or more individuals (as defined in 45 CFR 160.103). Such events and phenomena, when caused or contributed to by health information technology certified as a Health IT Module or as part of a certified Health IT Module (as defined in this section), are non-conformities to the ONC Health IT Certification Program requirements. This would be true even in situations where such certified Health IT Modules pass laboratory or in-the-field testing protocols for conformance to specific standards adopted in subpart B or criteria adopted in subpart C of this part. This definition includes, but is not limited to, the following:
                        </P>
                        <P>(1) Erasure, other destruction, or truncation of some or all of one or more clinical data entries or of one or more points of metadata needed to maintain and demonstrate the integrity of the clinical data points (excluding erasure, destruction, or truncation commanded by a system administrator or user).</P>
                        <P>(2) Corruption of clinical data in one or more elements of any patient or patients' data through the certified health information technology's operation or interaction with other technology resulting in:</P>
                        <P>(i) Comingling or conflation of separate patients' information in a single record or user-interface display or screen, such that the comingled or conflated data appears to the end user to be a single patient's information.</P>
                        <P>
                            (ii) Display of multiple patients' information on a single user interface screen or display without accurate 
                            <PRTPAGE P="63767"/>
                            indication to the end user of which data pertains to which patient.
                        </P>
                        <P>(iii) Attributing clinical documentation entered by an end user to a different patient than the patient whose record is identified to the end user as the destination of the documentation during the user's data entry.</P>
                        <P>(iv) Failure to accurately record and maintain the semantic meaning of documentation entries.</P>
                        <P>(v) Substitution of documentation entries from sources not selected or authorized by a user (excluding as a result of accurately executed, intentionally automated functions known to and approved by the user or user organization).</P>
                        <P>(3) Loss of clinical order data integrity, such as:</P>
                        <P>(i) Changes in numerical values for a prescription or treatment dose, frequency, quantity, or concentration that are not commanded by a user (excluding intentionally automated, accurate unit conversions).</P>
                        <P>(ii) Changes in a drug name, class, active ingredients, dose, form, or route of administration not commanded by a user (excluding intentionally automated, accurate substitution of nonproprietary names for brand names of the same drug or biologic).</P>
                        <P>(iii) Erroneously indicating to a clinician entering, or other user(s) reviewing, orders that an order has been sent when it has not been sent.</P>
                        <P>(iv) Failure to send orders to the recipient or destination designated by a human end user or by accurate, intentional automation of a health care provider's standard routing based on order characteristics.</P>
                        <P>(v) Failure to accurately execute an authorized user's command to delete, cancel, or discontinue a medication, treatment, or other clinical order.</P>
                        <P>(vi) Persistently listing a medication or treatment order as current or active after it was cancelled or otherwise intentionally discontinued.</P>
                        <P>(4) Creation, revision, update, or deletion of one or more data points within a patient record or of an entire record, other than as commanded by an authorized user or through accurate execution of an intentionally automated data feed or capture process.</P>
                        <P>(5) Failure to accurately execute authorized user commands to create, revise, update, or delete clinical notes or other documentation within a patient's record.</P>
                        <P>(6) Failure to maintain accurate logs of revisions or edits to any data within a patient record, including but not limited to accurate attribution of each revision to the human user or automated process making the change.</P>
                    </SECTION>
                    <AMDPAR>4. Amend § 170.205 by:</AMDPAR>
                    <AMDPAR>a. Adding paragraph (a)(1);</AMDPAR>
                    <AMDPAR>b. Revising paragraph (a)(6);</AMDPAR>
                    <AMDPAR>c. Adding paragraph (d)(1);</AMDPAR>
                    <AMDPAR>d. Revising paragraph (d)(2) and (4);</AMDPAR>
                    <AMDPAR>e. Adding paragraph (e)(1);</AMDPAR>
                    <AMDPAR>f. Revising paragraph (e)(4);</AMDPAR>
                    <AMDPAR>g. Revising and republishing paragraph (g);</AMDPAR>
                    <AMDPAR>h. Revising paragraphs (h)(2) and (3);</AMDPAR>
                    <AMDPAR>i. Adding paragraphs (i)(3) and (4);</AMDPAR>
                    <AMDPAR>j. Revising paragraph (k)(1);</AMDPAR>
                    <AMDPAR>k. Removing and reserving paragraph (k)(2);</AMDPAR>
                    <AMDPAR>l. Revising paragraphs (k)(3) and (r)(1);</AMDPAR>
                    <AMDPAR>m. Adding paragraph (r)(2);</AMDPAR>
                    <AMDPAR>n. Revising (s)(1);</AMDPAR>
                    <AMDPAR>o. Adding paragraph (s)(2);</AMDPAR>
                    <AMDPAR>p. Revising paragraph (t)(2); and</AMDPAR>
                    <AMDPAR>q. Adding paragraph (v).</AMDPAR>
                    <P>The additions, revisions, and republication read as follows:</P>
                    <SECTION>
                        <SECTNO>§ 170.205</SECTNO>
                        <SUBJECT>Content exchange standards and implementation specifications for exchanging electronic health information.</SUBJECT>
                        <STARS/>
                        <P>(a) * * *</P>
                        <P>
                            (1) 
                            <E T="03">Standard.</E>
                             HL7® CDA® R2 Implementation Guide: Consolidated CDA (C-CDA) Templates for Clinical Notes, Edition 3—US Realm (C-CDA Edition 3) (incorporated by reference, see § 170.299).
                        </P>
                        <STARS/>
                        <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). The adoption of this standard expires on January 1, 2028.
                        </P>
                        <P>(d) * * *</P>
                        <P>
                            (1) 
                            <E T="03">Standard.</E>
                             HL7 Version 2.5.1 Implementation Guide: Syndromic Surveillance, Release 1—US Realm Standard for Trial Use (incorporated by reference in § 170.299).
                        </P>
                        <P>
                            (2) 
                            <E T="03">Standard.</E>
                             HL7 2.5.1 (incorporated by reference in § 170.299). The adoption of this standard expires on January 1, 2027 for the purposes of the certification criteria in § 170.315(f).
                        </P>
                        <STARS/>
                        <P>
                            (4) 
                            <E T="03">Standard.</E>
                             HL7 2.5.1 (incorporated by reference in § 170.299). Implementation specifications. PHIN Messaging Guide for Syndromic Surveillance: Emergency Department, Urgent Care, Inpatient and Ambulatory Care Settings, Release 2.0, April 21, 2015 (incorporated by reference in § 170.299) and Erratum to the CDC PHIN 2.0 Implementation Guide, August 2015; Erratum to the CDC PHIN 2.0 Messaging Guide, April 2015 Release for Syndromic Surveillance: Emergency Department, Urgent Care, Inpatient and Ambulatory Care Settings (incorporated by reference in § 170.299). The adoption of this standard expires on January 1, 2027.
                        </P>
                        <P>(e) * * *</P>
                        <P>
                            (1) 
                            <E T="03">Standard.</E>
                             HL7 Version 2.5.1 Implementation Guide for Immunization Messaging, Release 1.5, 2018 Update (incorporated by reference in § 170.299).
                        </P>
                        <STARS/>
                        <STARS/>
                        <P>
                            (4) 
                            <E T="03">Standard.</E>
                             HL7 2.5.1 (incorporated by reference in § 170.299). Implementation specifications. HL7 2.5.1 Implementation Guide for Immunization Messaging, Release 1.5 (incorporated by reference in § 170.299) and HL7 Version 2.5.1 Implementation Guide for Immunization Messaging (Release 1.5)—Addendum, July 2015 (incorporated by reference in § 170.299). The adoption of this standard expires on January 1, 2028.
                        </P>
                        <STARS/>
                        <P>
                            (g) 
                            <E T="03">Electronic transmission of laboratory results to public health agencies</E>
                            —(1) 
                            <E T="03">Standard.</E>
                             HL7 2.5.1 (incorporated by reference in § 170.299). Implementation specifications. HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health, Release 1 (US Realm) (ELR) (incorporated by reference in § 170.299) with Errata and Clarifications, (incorporated by reference in § 170.299) and ELR 2.5.1 Clarification Document for EHR Technology Certification, (incorporated by reference in § 170.299). The adoption of this standard expires on January 1, 2028.
                        </P>
                        <P>
                            (2) 
                            <E T="03">Standard.</E>
                             HL7 Version 2.5.1 Implementation Guide: Laboratory Orders Interface (LOI) from EHR, Release 1, STU Release 4—US Realm (incorporated by reference in § 170.299).
                        </P>
                        <P>
                            (3) 
                            <E T="03">Standard.</E>
                             HL7 Version 2.5.1 Implementation Guide: Laboratory Results Interface (LRI), Release 1 STU Release 4—US Realm (incorporated by reference in § 170.299).
                        </P>
                        <P>(h) * * *</P>
                        <P>
                            (2) 
                            <E T="03">Standard.</E>
                             HL7 CDA® R2 Implementation Guide: Quality Reporting Document Architecture—Category I (QRDA I)—US Realm, STU 5.3 with errata (incorporated by reference in § 170.299).
                        </P>
                        <P>
                            (3) 
                            <E T="03">Standard.</E>
                             CMS Implementation Guide for Quality Reporting Document Architecture Category I Hospital Quality Reporting, Implementation Guide for 2024, Version 1.1 (incorporated by reference in § 170.299).
                        </P>
                        <P>
                            (i) * * *
                            <PRTPAGE P="63768"/>
                        </P>
                        <P>
                            (3) 
                            <E T="03">Standard.</E>
                             HL7 FHIR Central Cancer Registry Reporting Content IG, 1.0.0—STU 1 (incorporated by reference in § 170.299).
                        </P>
                        <P>
                            (4) 
                            <E T="03">Standard.</E>
                             HL7 FHIR Cancer Pathology Data Sharing, 1.0.0—STU1 (incorporated by reference in § 170.299).
                        </P>
                        <STARS/>
                        <P>(k) * * *</P>
                        <P>
                            (1) 
                            <E T="03">Standard</E>
                             HL7 CDA® R2 Implementation Guide: Quality Reporting Document Architecture (QRDA III), Release 1—US Realm (ANSI/HL7 Normative Release 1) (incorporated by reference in § 170.299).
                        </P>
                        <P>(2) [Reserved]</P>
                        <P>
                            (3) 
                            <E T="03">Standard.</E>
                             CMS Implementation Guide for Quality Reporting Document Architecture Category III, Eligible Clinicians Programs, Implementation Guide for 2024, Version 1.1 (incorporated by reference in § 170.299).
                        </P>
                        <STARS/>
                        <P>(r) * * *</P>
                        <P>
                            (1) 
                            <E T="03">Standard.</E>
                             The following sections of HL7 Implementation Guide for CDA® Release 2—Level 3: Healthcare Associated Infection Reports, Release 1, U.S. Realm (incorporated by reference in § 170.299). The adoption of this standard expires on January 1, 2027. Technology is only required to conform to the following sections of the implementation guide:
                        </P>
                        <P>(i) For the time period up to and including December 31, 2025, HAI Antimicrobial Use and Resistance (AUR) Antimicrobial Resistance Option (ARO) Report (Numerator) specific document template in Section 2.1.2.1 (pages 69-72);</P>
                        <P>(ii) For the time period up to and including December 31, 2025, Antimicrobial Resistance Option (ARO) Summary Report (Denominator) specific document template in Section 2.1.1.1 (pages 54-56); and</P>
                        <P>(iii) Antimicrobial Use (AUP) Summary Report (Numerator and Denominator) specific document template in Section 2.1.1.2 (pages 56-58).</P>
                        <P>
                            (2) 
                            <E T="03">Standard.</E>
                             The following sections of HL7 CDA® R2 Implementation Guide: Healthcare Associated Infection (HAI) Reports, Release 3—U.S. Realm (incorporated by reference in § 170.299). Technology is only required to conform to the following sections of the implementation guide:
                        </P>
                        <P>(i) HAI Antimicrobial Use and Resistance (AUR) Antimicrobial Resistance Option (ARO) Report (Numerator);</P>
                        <P>(ii) Antimicrobial Resistance Option (ARO) Summary Report (Denominator); and,</P>
                        <P>(iii) Antimicrobial Use (AUP) Summary Report (Numerator and Denominator).</P>
                        <P>(s) * * *</P>
                        <P>
                            (1) 
                            <E T="03">Standard.</E>
                             HL7 Implementation Guide for CDA® Release 2: National Health Care Surveys (NHCS), Release 1—US Realm, HL7 Draft Standard for Trial Use, Volume 1—Introductory Material and HL7 Implementation Guide for CDA® Release 2: National Health Care Surveys (NHCS), Release 1—US Realm, HL7 Draft Standard for Trial Use, Volume 2—Templates and Supporting Material (incorporated by reference in § 170.299). The adoption of this standard expires on January 1, 2027.
                        </P>
                        <P>
                            (2) 
                            <E T="03">Standard.</E>
                             HL7 CDA® R2 Implementation Guide: National Health Care Surveys (NHCS), R1 STU Release 3.1—US Realm (incorporated by reference in § 170.299).
                        </P>
                        <P>(t) * * *</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 in § 170.299). The adoption of this standard expires on January 1, 2028.
                        </P>
                        <STARS/>
                        <P>
                            (v) 
                            <E T="03">Public health—birth reporting</E>
                            —(1) 
                            <E T="03">Standard.</E>
                             HL7 FHIR Vital Records Birth and Fetal Death Reporting 1.1.0—STU 1.1 (incorporated by reference in § 170.299).
                        </P>
                        <P>(2) [Reserved]</P>
                    </SECTION>
                    <AMDPAR>5. Amend § 170.207 by:</AMDPAR>
                    <AMDPAR>a. Revising paragraph (a)(1);</AMDPAR>
                    <AMDPAR>b. Adding (a)(2);</AMDPAR>
                    <AMDPAR>c. Revising paragraphs (a)(4) and (c);</AMDPAR>
                    <AMDPAR>d. Revising and republishing paragraphs (d) and (e);</AMDPAR>
                    <AMDPAR>e. Revising paragraphs (f)(1) and (2);</AMDPAR>
                    <AMDPAR>f. Removing and reserving paragraph (f)(3);</AMDPAR>
                    <AMDPAR>g. Revising paragraphs (m)(1), (n)(1) introductory text, and (n)(2) and (3);</AMDPAR>
                    <AMDPAR>h. Revising and republishing paragraphs (o) and (p); and</AMDPAR>
                    <AMDPAR>i. Revising paragraphs (r)(1) and (s)(1).</AMDPAR>
                    <P>The revisions, additions, and republications 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). The adoption of this standard expires on January 1, 2028.
                        </P>
                        <P>
                            (2) 
                            <E T="03">Standard.</E>
                             SNOMED CT®, U.S. Edition, September 2023 Release (incorporated by reference in § 170.299).
                        </P>
                        <STARS/>
                        <P>
                            (4) 
                            <E T="03">Standard.</E>
                             IHTSDO SNOMED CT®, U.S. Edition, September 2015 Release (incorporated by reference in § 170.299). The adoption of this standard expires on January 1, 2026.
                        </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). The adoption of this standard expires on January 1, 2028.
                        </P>
                        <P>
                            (2) 
                            <E T="03">Standard.</E>
                             Logical Observation Identifiers Names and Codes (LOINC®) Database version 2.76, a universal code system for identifying laboratory and clinical observations produced by the Regenstrief Institute, Inc. (incorporated by reference in § 170.299).
                        </P>
                        <P>
                            (3) 
                            <E T="03">Standard.</E>
                             Logical Observation Identifiers Names and Codes (LOINC®) Database version 2.52, a universal code system for identifying laboratory and clinical observations produced by the Regenstrief Institute, Inc. (incorporated by reference in § 170.299). The adoption of this standard expires on January 1, 2026.
                        </P>
                        <STARS/>
                        <P>
                            (d) 
                            <E T="03">Medications—</E>
                            (1) 
                            <E T="03">Clinical drugs</E>
                            —(i) 
                            <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). The adoption of this standard expires on January 1, 2028.
                        </P>
                        <P>
                            (ii) 
                            <E T="03">Standard.</E>
                             RxNorm, a standardized nomenclature for clinical drugs produced by the United States National Library of Medicine, December 4, 2023, Full Monthly Release (incorporated by reference in § 170.299).
                        </P>
                        <P>
                            (iii) 
                            <E T="03">Standard.</E>
                             RxNorm, a standardized nomenclature for clinical drugs produced by the United States National Library of Medicine, September 8, 2015 Release (incorporated by reference in § 170.299). The adoption of this standard expires on January 1, 2026.
                        </P>
                        <P>
                            (2) 
                            <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>(3) [Reserved]</P>
                        <P>
                            (e) 
                            <E T="03">Immunizations—</E>
                            (1) 
                            <E T="03">Standard.</E>
                             HL7® Standard Code Set CVX—Vaccines Administered, dated through June 15, 2022 (incorporated by reference, see § 170.299). The adoption of this standard expires on January 1, 2028.
                        </P>
                        <P>
                            (2) 
                            <E T="03">Standard.</E>
                             National Drug Code Directory (NDC)—Vaccine NDC Linker, 
                            <PRTPAGE P="63769"/>
                            dated July 19, 2022 (incorporated by reference, see § 170.299). The adoption of this standard expires on January 1, 2028.
                        </P>
                        <P>
                            (3) 
                            <E T="03">Standard.</E>
                             HL7 Standard Code Set CVX—Vaccines Administered, updates through August 17, 2015 (incorporated by reference in § 170.299). The adoption of this standard expires on January 1, 2026.
                        </P>
                        <P>
                            (4) 
                            <E T="03">Standard.</E>
                             National Drug Code Directory (NDC)—Vaccine NDC Linker, updates through August 17, 2015 (incorporated by reference in § 170.299). The adoption of this standard expires on January 1, 2026
                        </P>
                        <P>
                            (5) 
                            <E T="03">Standard.</E>
                             CDC National Center of Immunization and Respiratory Diseases (NCIRD) Code Set (CVX)—Vaccines Administered, updates through September 29, 2023 (incorporated by reference in § 170.299).
                        </P>
                        <P>
                            (6) 
                            <E T="03">Standard.</E>
                             National Drug Code Directory (NDC)—Vaccine NDC Linker, updates through November 6, 2023 (incorporated by reference in § 170.299).
                        </P>
                        <P>(f) * * *</P>
                        <P>
                            (1) 
                            <E T="03">Standard.</E>
                             The Office of Management and Budget Standards for Maintaining, Collecting, and Presenting Federal Data on Race and Ethnicity, Statistical Policy Directive No. 15.
                        </P>
                        <P>(i) The Office of Management and Budget Standards for Maintaining, Collecting, and Presenting Federal Data on Race and Ethnicity, Statistical Policy Directive No. 15, as revised, October 30, 1997. The adoption of this standard expires on January 1, 2026.</P>
                        <P>(ii) U.S. Office of Management and Budget's Statistical Policy Directive No. 15: Standards for Maintaining, Collecting, and Presenting Federal Data on Race and Ethnicity (SPD 15), as revised, March 29, 2024.</P>
                        <P>
                            (2) 
                            <E T="03">Standard.</E>
                             CDC Race and Ethnicity Code Set:
                        </P>
                        <P>(i) CDC Race and Ethnicity Code Set Version 1.0 (March 2000) (incorporated by reference in § 170.299). The adoption of this standard expires on January 1, 2026.</P>
                        <P>(ii) CDC Race and Ethnicity Code Set Version 1.2 (July 08, 2021) (incorporated by reference, see § 170.299).</P>
                        <STARS/>
                        <P>(m) * * *</P>
                        <P>
                            (1) 
                            <E T="03">Standard.</E>
                             The Unified Code of Units of Measure, Revision 1.9 (incorporated by reference in § 170.299). The adoption of this standard expires on January 1, 2026.
                        </P>
                        <STARS/>
                        <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>
                        <STARS/>
                        <P>
                            (2) 
                            <E T="03">Standard.</E>
                             Sex must be coded in accordance with, at a minimum, at least one of the versions of SNOMED CT® codes specified in paragraph (a) of this section.
                        </P>
                        <P>
                            (3) 
                            <E T="03">Standard.</E>
                             Sex for Clinical Use must be coded in accordance with, at a minimum, at least one of the versions of LOINC® codes specified in paragraph (c) 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, at least one of the versions of SNOMED-CT® U.S. Edition codes specified in paragraph (a) 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>
                        <FP SOURCE="FP-1">
                            (i) 
                            <E T="03">Lesbian, gay, or homosexual.</E>
                             38628009
                        </FP>
                        <FP SOURCE="FP-1">
                            (ii) 
                            <E T="03">Straight or heterosexual.</E>
                             20430005
                        </FP>
                        <FP SOURCE="FP-1">
                            (iii) 
                            <E T="03">Bisexual.</E>
                             42035005
                        </FP>
                        <FP SOURCE="FP-1">
                            (iv) 
                            <E T="03">Something else, please describe.</E>
                             NullFlavor OTH
                        </FP>
                        <FP SOURCE="FP-1">
                            (v) 
                            <E T="03">Don't know.</E>
                             NullFlavor UNK
                        </FP>
                        <FP SOURCE="FP-1">
                            (vi) 
                            <E T="03">Choose not to disclose.</E>
                             NullFlavor ASKU
                        </FP>
                        <P>
                            (2) 
                            <E T="03">Standard.</E>
                             Gender identity must be coded in accordance with, at a minimum, at least one of the versions of SNOMED-CT® U.S. Edition codes specified in paragraph (a) 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>
                        <FP SOURCE="FP-1">
                            (i) 
                            <E T="03">Male.</E>
                             446151000124109
                        </FP>
                        <FP SOURCE="FP-1">
                            (ii) 
                            <E T="03">Female.</E>
                             446141000124107
                        </FP>
                        <FP SOURCE="FP-1">
                            (iii) 
                            <E T="03">Female-to-Male (FTM)/Transgender Male/Trans Man.</E>
                             407377005
                        </FP>
                        <FP SOURCE="FP-1">
                            (iv) 
                            <E T="03">Male-to-Female (MTF)/Transgender Female/Trans Woman.</E>
                             407376001
                        </FP>
                        <FP SOURCE="FP-1">
                            (v) 
                            <E T="03">Genderqueer, neither exclusively male nor female.</E>
                             446131000124102
                        </FP>
                        <FP SOURCE="FP-1">
                            (vi) 
                            <E T="03">Additional gender category or other, please specify.</E>
                             NullFlavor OTH
                        </FP>
                        <FP SOURCE="FP-1">
                            (vii) 
                            <E T="03">Choose not to disclose.</E>
                             NullFlavor ASKU
                        </FP>
                        <P>
                            (3) 
                            <E T="03">Standard.</E>
                             Sexual Orientation and Gender Identity must be coded in accordance with, at a minimum, the at least one of the versions of SNOMED CT® U.S. Edition codes specified in paragraph (a) of this section.
                        </P>
                        <P>
                            (4) 
                            <E T="03">Standard.</E>
                             Pronouns must be coded in accordance with, at a minimum, at least one of the versions of LOINC codes specified in paragraph (c) 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, at least one of the versions of LOINC® codes specified in paragraph (c) 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, at least one of the versions of LOINC® codes specified in paragraph (c) 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, at least one of the versions of LOINC® codes specified in paragraph (c) 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, at least one of the versions of LOINC® codes specified in paragraph (c) 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 at least one of the versions of the standard specified in paragraph (m) of this section).
                        </P>
                        <P>
                            (5) 
                            <E T="03">Physical activity.</E>
                             Physical activity must be coded in accordance with, at a minimum, at least one of the versions of LOINC® codes specified in paragraph (c) 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 at least one of the versions of the standard specified in paragraph (m) of this section.
                        </P>
                        <P>
                            (6) 
                            <E T="03">Alcohol use.</E>
                             Alcohol use must be coded in accordance with, at a minimum, at least one of the versions of LOINC® codes specified in paragraph (c) 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 at least one of the versions of the 
                            <PRTPAGE P="63770"/>
                            standard specified in § paragraph (m) of this section).
                        </P>
                        <P>
                            (7) 
                            <E T="03">Social connection and isolation.</E>
                             Social connection and isolation must be coded in accordance with, at a minimum, at least one of the versions of LOINC® codes specified in paragraph (c) 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 § 170.207(m)(2)), 76509-9 (with the associated applicable unit of measure in at least one of the versions of the standard specified in paragraph (m) of this section), 76510-7 (with the associated applicable unit of measure in at least one of the versions of the standard specified in paragraph (m)), 76511-5 (with LOINC answer list ID LL963-0), and 76512-3 (with the associated applicable unit of measure in at least one of the versions of the standard specified in paragraph (m) 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, at least one of the versions of LOINC® codes specified in paragraph (c) 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 at least one of the versions of the standard specified in paragraph (m) of this section).
                        </P>
                        <STARS/>
                        <P>(r) * * *</P>
                        <P>
                            (1) 
                            <E T="03">Standard.</E>
                             Crosswalk: Medicare Provider/Supplier to Healthcare Provider Taxonomy, April 2, 2015 (incorporated by reference in § 170.299). The adoption of this standard expires on January 1, 2026.
                        </P>
                        <STARS/>
                        <P>(s) * * *</P>
                        <P>
                            (1) 
                            <E T="03">Standard.</E>
                             Public Health Data Standards Consortium Source of Payment Typology Code Set Version 5.0 (October 2011) (incorporated by reference in § 170.299). The adoption of this standard expires on January 1, 2026.
                        </P>
                        <STARS/>
                    </SECTION>
                    <AMDPAR>6. Amend § 170.210 by revising paragraph (a)(2), adding paragraph (a)(3), and removing and reserving paragraph (f) 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>(a) * * *</P>
                        <P>
                            (2) 
                            <E T="03">General.</E>
                             Any encryption algorithm identified by the National Institute of Standards and Technology (NIST) as an approved security function in Annex A of the Federal Information Processing Standards (FIPS) Publication 140-2, October 8, 2014 (incorporated by reference in § 170.299). The adoption of this standard expires on January 1, 2026.
                        </P>
                        <P>
                            (3) 
                            <E T="03">General.</E>
                             Any encryption algorithm identified by the National Institute of Standards and Technology (NIST) as an approved security function in Annex A of the Federal Information Processing Standards (FIPS) Publication 140-2, October 12, 2021 (incorporated by reference in § 170.299).
                        </P>
                        <STARS/>
                    </SECTION>
                    <AMDPAR>7. Amend § 170.213 by revising paragraph (b) and adding paragraph (c) to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 170.213</SECTNO>
                        <SUBJECT>United States Core Data for Interoperability.</SUBJECT>
                        <STARS/>
                        <P>
                            (b) 
                            <E T="03">Standard.</E>
                             United States Core Data for Interoperability (USCDI) Version 3 (v3), October 2022 Errata, (incorporated by reference in § 170.299). The adoption of this standard expires on January 1, 2028.
                        </P>
                        <P>
                            (c) 
                            <E T="03">Standard.</E>
                             United States Core Data for Interoperability (USCDI) Version 4 (v4), October 2023 Errata, (incorporated by reference in § 170.299).
                        </P>
                    </SECTION>
                    <AMDPAR>8. Amend § 170.215 by:</AMDPAR>
                    <AMDPAR>a. Revising paragraph (b)(1)(ii);</AMDPAR>
                    <AMDPAR>b. Adding paragraphs (b)(1)(iii) and (b)(2);</AMDPAR>
                    <AMDPAR>c. Revising paragraphs (c)(1) and (2);</AMDPAR>
                    <AMDPAR>d. Adding paragraph (c)(3);</AMDPAR>
                    <AMDPAR>e. Revising paragraphs (d)(1); and</AMDPAR>
                    <AMDPAR>f. Adding paragraphs (d)(2) and (f) through (o).</AMDPAR>
                    <P>The revisions and additions read as follows:</P>
                    <SECTION>
                        <SECTNO>§ 170.215</SECTNO>
                        <SUBJECT>Application Programming Interface Standards.</SUBJECT>
                        <STARS/>
                        <P>(b) * * *</P>
                        <P>(1) * * *</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). The adoption of this standard expires on January 1, 2028.
                        </P>
                        <P>
                            (iii) 
                            <E T="03">Implementation specification.</E>
                             HL7 FHIR® US Core Implementation Guide, Version 7.0.0—STU7, (incorporated by reference, see § 170.299).
                        </P>
                        <P>
                            (2) 
                            <E T="03">Implementation specification.</E>
                             HL7 FHIR® US Public Health Profiles Library Implementation Guide. US Public Health Profiles Library 1.0.0—STU1 (incorporated by reference in § 170.299).
                        </P>
                        <P>(c) * * *</P>
                        <P>
                            (1) 
                            <E T="03">Implementation specification.</E>
                             HL7® SMART Application Launch Framework Implementation Guide Release 1.0.0 (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 (incorporated by reference, see § 170.299). The adoption of this standard expires on January 1, 2028.
                        </P>
                        <P>
                            (3) 
                            <E T="03">Implementation specification.</E>
                             HL7® SMART App Launch Implementation Guide Release 2.2.0—STU 2.2 (incorporated by reference, see § 170.299).
                        </P>
                        <P>(d) * * *</P>
                        <P>
                            (1) 
                            <E T="03">Implementation specification.</E>
                             HL7® FHIR® Bulk Data Access (Flat FHIR) (v1.0.0—STU 1) (incorporated by reference, see § 170.299). The adoption of this standard expires on January 1, 2028.
                        </P>
                        <P>
                            (2) 
                            <E T="03">Implementation specification.</E>
                             HL7® FHIR® Bulk Data Access IG 2.0.0—STU 2, (incorporated by reference, see § 170.299).
                        </P>
                        <STARS/>
                        <P>
                            (f) 
                            <E T="03">API-based workflow triggers.</E>
                             The following are applicable for purposes of initiating calls to decision support services or initiating interactions that can be presented to users synchronously in their workflows.
                        </P>
                        <P>
                            (1) 
                            <E T="03">Implementation specification.</E>
                             HL7® CDS Hooks Release 2.0 (incorporated by reference in § 170.299).
                        </P>
                        <P>(2) [Reserved]</P>
                        <P>
                            (g) 
                            <E T="03">Verifiable health records.</E>
                             The following are applicable for purposes of issuing verifiable and sharable health information and health records.
                        </P>
                        <P>
                            (1) 
                            <E T="03">SMART Health Cards Framework</E>
                            —(i) 
                            <E T="03">Implementation specification.</E>
                             HL7® FHIR® SMART Health Cards Framework version 1.4.0 (incorporated by reference in § 170.299).
                        </P>
                        <P>(ii) [Reserved]</P>
                        <P>
                            (2) 
                            <E T="03">Vaccination and Testing</E>
                            —(i) 
                            <E T="03">Implementation specification.</E>
                             SMART Health Cards: Vaccination and Testing Implementation Guide Version 1.0.0—STU 1 (incorporated by reference in § 170.299).
                        </P>
                        <P>(ii) [Reserved]</P>
                        <P>
                            (h) 
                            <E T="03">API-based event notifications.</E>
                             The following are applicable for the purposes of supporting proactive notifications from a server to a client when new information has been added or existing information has been updated.
                            <PRTPAGE P="63771"/>
                        </P>
                        <P>
                            (1) 
                            <E T="03">FHIR Subscriptions: Implementation specification.</E>
                             HL7® FHIR® Subscriptions R5 Backport Implementation Guide Version 1.1.0—Standard for Trial Use (incorporated by reference in § 170.299).
                        </P>
                        <P>(2) [Reserved]</P>
                        <P>(i) [Reserved]</P>
                        <P>
                            (j) 
                            <E T="03">Prior authorization</E>
                            —(1) 
                            <E T="03">Coverage requirements discovery</E>
                            —(i) 
                            <E T="03">Implementation specification.</E>
                             HL7 FHIR® Da Vinci—Coverage Requirements Discovery (CRD) Implementation Guide, Version 2.0.1—STU 2 (incorporated by reference in § 170.299).
                        </P>
                        <P>(ii) [Reserved]</P>
                        <P>
                            (2) 
                            <E T="03">Prior authorization documentation</E>
                            —(i) 
                            <E T="03">Implementation specification.</E>
                             HL7 FHIR® Da Vinci—Documentation Templates and Rules (DTR) Implementation Guide: Version 2.0.1—STU 2 (incorporated by reference in § 170.299).
                        </P>
                        <P>(ii) [Reserved]</P>
                        <P>
                            (3) 
                            <E T="03">Prior authorization submission</E>
                            —(i) 
                            <E T="03">Implementation specification.</E>
                             HL7 FHIR Da Vinci—Prior Authorization Support (PAS) FHIR Implementation Guide: Version 2.0.1—STU 2 (incorporated by reference in § 170.299).
                        </P>
                        <P>(ii) [Reserved]</P>
                        <P>
                            (k) 
                            <E T="03">Payer data exchange</E>
                            —(1) 
                            <E T="03">Blue button</E>
                            —(i) 
                            <E T="03">Implementation specification.</E>
                             HL7 FHIR Consumer Directed Payer Data Exchange (CARIN IG for Blue Button®) Implementation Guide: Version 2.0.0—STU 2 (incorporated by reference in § 170.299).
                        </P>
                        <P>(ii) [Reserved]</P>
                        <P>
                            (2) 
                            <E T="03">Payer data exchange</E>
                            —(i) 
                            <E T="03">Implementation specification.</E>
                             HL7 FHIR® Da Vinci Payer Data Exchange (PDex) Implementation Guide: Version 2.0.0 STU—2.0.0 (incorporated by reference in § 170.299).
                        </P>
                        <P>(ii) [Reserved]</P>
                        <P>(l) [Reserved]</P>
                        <P>
                            (m) 
                            <E T="03">Drug formulary</E>
                            —(1) 
                            <E T="03">Implementation specification.</E>
                             HL7 FHIR® Da Vinci—Payer Data Exchange (PDex) US Drug Formulary Implementation Guide, Version 2.0.1—STU2 (incorporated by reference in § 170.299).
                        </P>
                        <P>(2) [Reserved]</P>
                        <P>
                            (n) 
                            <E T="03">Directory information</E>
                            —(1) 
                            <E T="03">Implementation specification.</E>
                             HL7 FHIR® Da Vinci payer Data Exchange (PDex) Plan Net Implementation Guide: Version 1.1.0—STU1.1 US (incorporated by reference in § 170.299).
                        </P>
                        <P>(2) [Reserved]</P>
                        <P>
                            (o) 
                            <E T="03">API functions using digital certificates.</E>
                             The following is applicable for purposes of API functions secured using digital certificates, including dynamic client registration.
                        </P>
                        <P>
                            (1) 
                            <E T="03">Implementation specification.</E>
                             HL7 FHIR® Unified Data Access Profiles (UDAP
                            <E T="51">TM</E>
                            ) Security for Scalable Registration, Authentication, and Authorization Implementation Guide Release 1.0.0—STU 1 US (incorporated by reference in § 170.299).
                        </P>
                        <P>(2) [Reserved]</P>
                    </SECTION>
                    <AMDPAR>9. Amend § 170.299 by:</AMDPAR>
                    <AMDPAR>a. Revising paragraphs (d)(14) and (15);</AMDPAR>
                    <AMDPAR>b. Adding paragraph (d)(20);</AMDPAR>
                    <AMDPAR>c. Revising paragraphs (e)(4) and (5);</AMDPAR>
                    <AMDPAR>d. Redesignating paragraphs (f) through (s) as paragraphs (g) through (t), respectively;</AMDPAR>
                    <AMDPAR>e. Adding new paragraph (f);</AMDPAR>
                    <AMDPAR>f. Revising newly redesignated paragraphs (h)(14) and (20);</AMDPAR>
                    <AMDPAR>h. Removing and reserving newly redesignated paragraphs (h)(21) and (24);</AMDPAR>
                    <AMDPAR>i. Adding paragraphs (h)(41) through (64);</AMDPAR>
                    <AMDPAR>j. Adding paragraphs (m)(3) and (5), and (n)(7);</AMDPAR>
                    <AMDPAR>k. Revising newly redesignated paragraph (q)(7); and</AMDPAR>
                    <AMDPAR>l. Adding paragraphs (s)(10) and (11).</AMDPAR>
                    <P>The revisions and additions read as follows:</P>
                    <SECTION>
                        <SECTNO>§ 170.299</SECTNO>
                        <SUBJECT>Incorporation by reference.</SUBJECT>
                        <STARS/>
                        <P>(d) * * *</P>
                        <P>(14) CDC National Center of Immunization and Respiratory Diseases (NCIRD) Code Set (CVX)—Vaccines Administered, updates through September 29, 2023, IBR approved for § 170.207(e).</P>
                        <P>(15) National Drug Code Directory (NDC)—Vaccine NDC Linker, updates through November 6, 2023, IBR approved for § 170.207(e).</P>
                        <STARS/>
                        <P>(20) HL7 Version 2.5.1 Implementation Guide for Immunization Messaging, Release 1.5, 2018 Update, IBR approved for § 170.205(e).</P>
                        <P>(e) * * *</P>
                        <P>(4) CMS Implementation Guide for Quality Reporting Document Architecture Category I Hospital Quality Reporting, Implementation Guide for 2024, Version 1.1, August 31, 2023, IBR approved for § 170.205(h).</P>
                        <P>(5) CMS Implementation Guide for Quality Reporting Document Architecture Category III, Eligible Clinicians Programs, Implementation Guide for 2024, Version 1.1, November 22, 2023, IBR approved for § 170.205(k).</P>
                        <STARS/>
                        <P>
                            (f) Computational Health Informatics Program, Boston Children's Hospital, 300 Longwood Avenue Boston, MA 02115, phone: (617) 355-6000, website: 
                            <E T="03">https://www.childrenshospital.org/research/programs/computational-health-informatics-program-research.</E>
                        </P>
                        <P>(1) SMART Health Cards Framework version 1.4.0, June 15, 2023, IBR approved for § 170.215(g).</P>
                        <P>(2) [Reserved]</P>
                        <STARS/>
                        <P>(h) * * *</P>
                        <P>(14) HL7 CDA® R2 Implementation Guide: Quality Reporting Document Architecture (QRDA III), Release 1—US Realm (ANSI/HL7 Normative Release 1), September 2021, IBR approved for § 170.205(k).</P>
                        <STARS/>
                        <P>(20) HL7 CDA® R2 Implementation Guide: Quality Reporting Document Architecture—Category I (QRDA I)—US Realm, STU 5.3 with errata, December 2022, IBR approved for § 170.205(h).</P>
                        <STARS/>
                        <P>(41) HL7 FHIR® Da Vinci—Coverage Requirements Discovery (CRD) Implementation Guide, Version 2.0.1—STU 2, January 8, 2024, IBR approved for § 170.215(j).</P>
                        <P>(42) HL7 FHIR® Da Vinci—Documentation Templates and Rules (DTR) FHIR Implementation Guide, Version 2.0.1—STU 2, January 11, 2024, IBR approved for § 170.215(j).</P>
                        <P>(43) HL7 FHIR® Da Vinci—Prior Authorization Support (PAS) FHIR Implementation Guide, Version 2.0.1—STU 2, December 1, 2023, IBR approved for § 170.215(j).</P>
                        <P>(44) HL7 FHIR® Consumer Directed Payer Data Exchange (CARIN IG for Blue Button®) Implementation Guide, Version 2.0.0—STU 2, November 28, 2022, IBR approved for § 170.215(k).</P>
                        <P>(45) HL7 FHIR® Da Vinci Payer Data Exchange (PDex) Implementation Guide, Version 2.0.0—STU 2, January 6, 2024, IBR approved for § 170.215(k).</P>
                        <P>(46) HL7 FHIR® Da Vinci—Payer Data Exchange (PDex) US Drug Formulary Implementation Guide, Version 2.0.1—STU2, December 1, 2023, IBR approved for § 170.215(m).</P>
                        <P>(47) HL7 FHIR® Da Vinci Payer Data Exchange (PDex) Plan Net Implementation Guide, Version 1.1.0—STU1.1 US, April 4, 2022, IBR approved for § 170.215(n).</P>
                        <P>(48) HL7 FHIR® Bulk Data Access IG 2.0.0—STU 2, November 26, 2021, IBR approved for § 170.215(d).</P>
                        <P>(49) HL7 FHIR® US Public Health Profiles Library Implementation Guide. US Public Health Profiles Library 1.0.0—STU1, October 4, 2023, IBR approved for § 170.215(b).</P>
                        <P>
                            (50) HL7 FHIR® Subscriptions R5 Backport Implementation Guide Version 1.1.0—Standard for Trial Use, January 11, 2022, IBR approved for § 170.215(h).
                            <PRTPAGE P="63772"/>
                        </P>
                        <P>(51) HL7® CDS Hooks Release 2.0, August 23, 2022, IBR approved for § 170.215(f).</P>
                        <P>(52) HL7 Version 2.5.1 Implementation Guide: Syndromic Surveillance, Release 1—US Realm Standard for Trial Use, July 2019, IBR approved for § 170.205(d).</P>
                        <P>(53) HL7 Version 2.5.1 Implementation Guide: Laboratory Orders (LOI) from EHR, Release 1, STU Release 4—US Realm, December 3, 2013, IBR approved for § 170.205(g).</P>
                        <P>(54) HL7 Version 2.5.1 Implementation Guide: Laboratory Results Interface (LRI), Release 1 STU Release 4—US Realm, July 16, 2012, IBR approved for § 170.205(g).</P>
                        <P>(55) HL7 FHIR® Central Cancer Registry Reporting Content IG, 1.0.0—STU 1, December 21, 2023, IBR approved for § 170.205(i).</P>
                        <P>(56) HL7 FHIR® Cancer Pathology Data Sharing, 1.0.0—STU1, August 18, 2023, IBR approved for § 170.205(i).</P>
                        <P>(57) HL7 CDA® R2 Implementation Guide: Healthcare Associated Infection (HAI) Reports, Release 3—US Realm, December 2, 2020. IBR approved for § 170.205(r)(2).</P>
                        <P>(58) HL7 CDA® R2 Implementation Guide: National Health Care Surveys (NHCS), R1 STU Release 3.1—US Realm, January 6, 2022, IBR approved for § 170.205(s).</P>
                        <P>(59) HL7 FHIR® Vital Records Birth and Fetal Death Reporting 1.1.0—STU 1.1, October 10, 2023, IBR approved for § 170.205(v).</P>
                        <P>(60) HL7 FHIR® SMART Health Cards: Vaccination and Testing Implementation Guide Version 1.0.0—STU 1 Release, December 27, 2023, IBR approved for § 170.215(g).</P>
                        <P>(61) HL7 FHIR® SMART App Launch Implementation Guide, Release 2.2.0—STU 2.2, April 30, 2024, IBR approved for § 170.215(c).</P>
                        <P>
                            (62) HL7 FHIR® Unified Data Access Profiles (UDAP
                            <SU>TM</SU>
                            ) Security for Scalable Registration, Authentication, and Authorization Implementation Guide, Release 1.0.0—STU 1 US, September 27, 2022, IBR approved for § 170.215(o).
                        </P>
                        <P>(63) HL7 FHIR® US Core Implementation Guide, Version 7.0.0—STU7, May 8, 2024, IBR approved for § 170.215(b).</P>
                        <P>(64) HL7 CDA® R2 Implementation Guide: Consolidated CDA (C-CDA) Templates for Clinical Notes, Edition 3—US Realm (C-CDA Edition 3), May 18, 2024, IBR approved for § 170.205(a).</P>
                        <STARS/>
                        <P>(m) * * *</P>
                        <P>(3) Annex A: Federal Information Processing Standards (FIPS) Publication 140-2, Security Requirements for Cryptographic Modules, October 8, 2014, IBR approved for § 170.210(a).</P>
                        <STARS/>
                        <P>(5) Annex A: A Federal Information Processing Standards (FIPS) Publication 140-2, Security Requirements for Cryptographic Modules, October 12, 2021, IBR approved for § 170.210(a).</P>
                        <P>(n) * * *</P>
                        <P>(7) United States Core Data for Interoperability (USCDI), Version 4 (v4), October 2023 Errata, IBR approved for § 170.213(c).</P>
                        <STARS/>
                        <P>(q) * * *</P>
                        <P>(7) Logical Observation Identifiers Names and Codes (LOINC®) Database Version 2.76, a universal code system for identifying laboratory and clinical observations produced by the Regenstrief Institute, Inc., September 18, 2023, IBR approved for § 170.207(c).</P>
                        <P>(s) * * *</P>
                        <P>(10) Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT®), U.S. Edition, September 2023 Release, IBR approved for § 170.207(a).</P>
                        <P>(11) RxNorm, a standardized nomenclature for clinical drugs produced by the United States National Library of Medicine, December 4, 2023, Full Monthly Release, IBR approved for § 170.207(d).</P>
                        <STARS/>
                    </SECTION>
                    <AMDPAR>10. Amend § 170.315 by:</AMDPAR>
                    <AMDPAR>a. Revising and republishing paragraphs (a) and (b);</AMDPAR>
                    <AMDPAR>b. Revising paragraph (c)(4)(iii);</AMDPAR>
                    <AMDPAR>c. Revising and republishing paragraphs (d) through (g); and</AMDPAR>
                    <AMDPAR>d. Adding paragraph (j).</AMDPAR>
                    <P>The revisions, republications, and addition read as follows:</P>
                    <SECTION>
                        <SECTNO>§ 170.315.</SECTNO>
                        <SUBJECT>ONC Certification Criteria for Health IT.</SUBJECT>
                        <STARS/>
                        <P>
                            (a) 
                            <E T="03">Clinical</E>
                            —(1) 
                            <E T="03">Computerized provider order entry—medications.</E>
                             (i) Enable a user to record, change, and access medication orders.
                        </P>
                        <P>
                            (ii) 
                            <E T="03">Optional.</E>
                             Include a “reason for order” field.
                        </P>
                        <P>
                            (2) 
                            <E T="03">Computerized provider order entry—laboratory.</E>
                             For the time period up to and including December 31, 2027, a Health IT Module must meet either the requirements specified in paragraph (a)(2)(i) of this section, or the requirements specified in paragraph (a)(2)(ii) of this section. On and after January 1, 2028, a Health IT Module must meet the requirements specified in paragraph (a)(2)(ii) of this section.
                        </P>
                        <P>(i) Enable a user to record, change, and access laboratory orders—the Health IT Module may include a “reason for order” field; or</P>
                        <P>(ii) Enable a user to:</P>
                        <P>(A) Record, change, and access laboratory orders—the Health IT Module may include a “reason for order” field;</P>
                        <P>(B) Create and transmit laboratory orders electronically according to the standard specified in § 170.205(g)(2); and</P>
                        <P>(C) Receive and validate laboratory results according to the standard specific in § 170.205(g)(3).</P>
                        <P>
                            (3) 
                            <E T="03">Computerized provider order entry—diagnostic imaging.</E>
                             (i) Enable a user to record, change, and access diagnostic imaging orders.
                        </P>
                        <P>
                            (ii) 
                            <E T="03">Optional.</E>
                             Include a “reason for order” field.
                        </P>
                        <P>
                            (4) 
                            <E T="03">Drug-drug, drug-allergy interaction checks for CPOE</E>
                            —(i) 
                            <E T="03">Interventions.</E>
                             Before a medication order is completed and acted upon during computerized provider order entry (CPOE), interventions must automatically indicate to a user drug-drug and drug-allergy contraindications based on a patient's medication list and medication allergy list.
                        </P>
                        <P>
                            (ii) 
                            <E T="03">Adjustments.</E>
                             (A) Enable the severity level of interventions provided for drug-drug interaction checks to be adjusted.
                        </P>
                        <P>(B) Limit the ability to adjust severity levels in at least one of these two ways:</P>
                        <P>
                            (
                            <E T="03">1</E>
                            ) To a specific set of identified users.
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) As a system administrative function.
                        </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) 
                            <E T="03">Race and ethnicity.</E>
                             (
                            <E T="03">1</E>
                            ) Enable each one of a patient's races to be recorded in accordance with, at a minimum, at least one of the standards specified in § 170.207(f)(2) 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, at least one of the standards specified in § 170.207(f)(2) and whether a patient declines to specify ethnicity.
                        </P>
                        <P>
                            (
                            <E T="03">3</E>
                            ) Aggregate each one of the patient's races and ethnicities recorded in accordance with paragraphs (a)(5)(i)(A)(
                            <E T="03">1</E>
                            ) and (
                            <E T="03">2</E>
                            ) of this section to the categories in at least one of the standards specified in § 170.207(f)(1).
                        </P>
                        <P>
                            (B) 
                            <E T="03">Preferred language.</E>
                             Enable preferred language to be recorded in accordance with the standard specified in § 170.207(g)(2) and whether a patient declines to specify a preferred language.
                            <PRTPAGE P="63773"/>
                        </P>
                        <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 paragraph (a)(5)(i)(F) of this section 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 paragraph (a)(5)(i)(G) of this section 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 paragraph (a)(5)(i)(H) of this section is required by January 1, 2026.
                        </P>
                        <P>
                            (ii) 
                            <E T="03">Inpatient setting only.</E>
                             Enable a user to record, change, and access the preliminary cause of death and date of death in the event of mortality.
                        </P>
                        <P>(6)-(8) [Reserved]</P>
                        <P>
                            (9) 
                            <E T="03">Clinical decision support (CDS)</E>
                            —(i) 
                            <E T="03">CDS intervention interaction.</E>
                             Interventions provided to a user must occur when a user is interacting with technology.
                        </P>
                        <P>
                            (ii) 
                            <E T="03">CDS configuration.</E>
                             (A) Enable interventions and reference resources specified in paragraphs (a)(9)(iii) and (iv) of this section to be configured by a limited set of identified users (
                            <E T="03">e.g.,</E>
                             system administrator) based on a user's role.
                        </P>
                        <P>(B) Enable interventions:</P>
                        <P>
                            (
                            <E T="03">1</E>
                            ) Based on the following data:
                        </P>
                        <P>
                            (
                            <E T="03">i</E>
                            ) Problem list;
                        </P>
                        <P>
                            (
                            <E T="03">ii</E>
                            ) Medication list;
                        </P>
                        <P>
                            (
                            <E T="03">iii</E>
                            ) Allergy and intolerance list;
                        </P>
                        <P>
                            (
                            <E T="03">iv</E>
                            ) At least one demographic specified in paragraph (a)(5)(i) of this section;
                        </P>
                        <P>
                            (
                            <E T="03">v</E>
                            ) Laboratory tests; and
                        </P>
                        <P>
                            (
                            <E T="03">vi</E>
                            ) Vital signs.
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) When a patient's medications, allergies and intolerance, and problems are incorporated from a transition of care/referral summary received and pursuant to paragraph (b)(2)(iii)(D) of this section.
                        </P>
                        <P>
                            (iii) 
                            <E T="03">Evidence-based decision support interventions.</E>
                             Enable a limited set of identified users to select (
                            <E T="03">i.e.,</E>
                             activate) electronic CDS interventions (in addition to drug-drug and drug-allergy contraindication checking) based on each one and at least one combination of the data referenced in paragraphs (a)(9)(ii)(B)(
                            <E T="03">1</E>
                            )(
                            <E T="03">i</E>
                            ) through (
                            <E T="03">vi</E>
                            ) of this section.
                        </P>
                        <P>
                            (iv) 
                            <E T="03">Linked referential CDS.</E>
                             (A) Identify for a user diagnostic and therapeutic reference information in accordance at least one of the following standards and implementation specifications:
                        </P>
                        <P>
                            (
                            <E T="03">1</E>
                            ) The standard and implementation specifications specified in § 170.204(b)(3).
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) The standard and implementation specifications specified in § 170.204(b)(4).
                        </P>
                        <P>
                            (B) For paragraph (a)(9)(iv)(A) of this section, technology must be able to identify for a user diagnostic or therapeutic reference information based on each one and at least one combination of the data referenced in paragraphs (a)(9)(ii)(B)(
                            <E T="03">1</E>
                            )(
                            <E T="03">i</E>
                            ), (
                            <E T="03">ii</E>
                            ), and (
                            <E T="03">iv</E>
                            ) of this section.
                        </P>
                        <P>
                            (v) 
                            <E T="03">Source attributes.</E>
                             Enable a user to review the attributes as indicated for all CDS resources:
                        </P>
                        <P>(A) For evidence-based decision support interventions under paragraph (a)(9)(iii) of this section:</P>
                        <P>
                            (
                            <E T="03">1</E>
                            ) Bibliographic citation of the intervention (clinical research/guideline);
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) Developer of the intervention (translation from clinical research/guideline);
                        </P>
                        <P>
                            (
                            <E T="03">3</E>
                            ) Funding source of the intervention development technical implementation; and
                        </P>
                        <P>
                            (
                            <E T="03">4</E>
                            ) Release and, if applicable, revision date(s) of the intervention or reference source.
                        </P>
                        <P>(B) For linked referential CDS in paragraph (a)(9)(iv) of this section and drug-drug, drug-allergy interaction checks in paragraph (a)(4) of this section, the developer of the intervention, and where clinically indicated, the bibliographic citation of the intervention (clinical research/guideline).</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>
                        <P>(10)-(11) [Reserved]</P>
                        <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, at least one of the versions of SNOMED CT U.S. Edition specified in § 170.207(a).
                        </P>
                        <P>(13) [Reserved]</P>
                        <P>
                            (14) 
                            <E T="03">Implantable device list.</E>
                             (i) Record Unique Device Identifiers associated with a patient's Implantable Devices.
                        </P>
                        <P>(ii) Parse the following identifiers from a Unique Device Identifier:</P>
                        <P>(A) Device Identifier; and</P>
                        <P>(B) The following identifiers that compose the Production Identifier:</P>
                        <P>
                            (
                            <E T="03">1</E>
                            ) The lot or batch within which a device was manufactured;
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) The serial number of a specific device;
                        </P>
                        <P>
                            (
                            <E T="03">3</E>
                            ) The expiration date of a specific device;
                        </P>
                        <P>
                            (
                            <E T="03">4</E>
                            ) The date a specific device was manufactured; and
                        </P>
                        <P>
                            (
                            <E T="03">5</E>
                            ) For an HCT/P regulated as a device, the distinct identification code required by 21 CFR 1271.290(c).
                        </P>
                        <P>(iii) Obtain and associate with each Unique Device Identifier:</P>
                        <P>(A) A description of the implantable device referenced by at least one of the following:</P>
                        <P>
                            (
                            <E T="03">1</E>
                            ) The “GMDN PT Name” attribute associated with the Device Identifier in the Global Unique Device Identification Database.
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) The “SNOMED CT® Description” mapped to the attribute referenced in paragraph (a)(14)(iii)(A)(
                            <E T="03">1</E>
                            ) of this section.
                        </P>
                        <P>(B) The following Global Unique Device Identification Database attributes:</P>
                        <P>
                            (
                            <E T="03">1</E>
                            ) “Brand Name”;
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) “Version or Model”;
                        </P>
                        <P>
                            (
                            <E T="03">3</E>
                            ) “Company Name”;
                        </P>
                        <P>
                            (
                            <E T="03">4</E>
                            ) “What MRI safety information does the labeling contain?”; and
                        </P>
                        <P>
                            (
                            <E T="03">5</E>
                            ) “Device required to be labeled as containing natural rubber latex or dry natural rubber (21 CFR 801.437).”
                        </P>
                        <P>(iv) Display to a user an implantable device list consisting of:</P>
                        <P>(A) The active Unique Device Identifiers recorded for the patient;</P>
                        <P>(B) For each active Unique Device Identifier recorded for a patient, the description of the implantable device specified by paragraph (a)(14)(iii)(A) of this section; and</P>
                        <P>(C) A method to access all Unique Device Identifiers recorded for a patient.</P>
                        <P>(v) For each Unique Device Identifier recorded for a patient, enable a user to access:</P>
                        <P>(A) The Unique Device Identifier;</P>
                        <P>(B) The description of the implantable device specified by paragraph (a)(14)(iii)(A) of this section;</P>
                        <P>
                            (C) The identifiers associated with the Unique Device Identifier, as specified by paragraph (a)(14)(ii) of this section; and
                            <PRTPAGE P="63774"/>
                        </P>
                        <P>(D) The attributes associated with the Unique Device Identifier, as specified by paragraph (a)(14)(iii)(B) of this section.</P>
                        <P>(vi) Enable a user to change the status of a Unique Device Identifier recorded for a patient.</P>
                        <P>
                            (15) 
                            <E T="03">Social, psychological, and behavioral data.</E>
                             Enable a user to record, change, and access the following patient social, psychological, and behavioral data:
                        </P>
                        <P>
                            (i) 
                            <E T="03">Financial resource strain.</E>
                             Enable financial resource strain to be recorded in accordance with the standard specified in § 170.207(p)(1) and whether a patient declines to specify financial resource strain.
                        </P>
                        <P>
                            (ii) 
                            <E T="03">Education.</E>
                             Enable education to be recorded in accordance with the standard specified in § 170.207(p)(2) and whether a patient declines to specify education.
                        </P>
                        <P>
                            (iii) 
                            <E T="03">Stress.</E>
                             Enable stress to be recorded in accordance with the standard specified in § 170.207(p)(3) and whether a patient declines to specify stress.
                        </P>
                        <P>
                            (iv) 
                            <E T="03">Depression.</E>
                             Enable depression to be recorded in accordance with the standard specified in § 170.207(p)(4) and whether a patient declines to specify depression.
                        </P>
                        <P>
                            (v) 
                            <E T="03">Physical activity.</E>
                             Enable physical activity to be recorded in accordance with the standard specified in § 170.207(p)(5) and whether a patient declines to specify physical activity.
                        </P>
                        <P>
                            (vi) 
                            <E T="03">Alcohol use.</E>
                             Enable alcohol use to be recorded in accordance with the standard specified in § 170.207(p)(6) and whether a patient declines to specify alcohol use.
                        </P>
                        <P>
                            (vii) 
                            <E T="03">Social connection and isolation.</E>
                             Enable social connection and isolation to be recorded in accordance the standard specified in § 170.207(p)(7) and whether a patient declines to specify social connection and isolation.
                        </P>
                        <P>
                            (viii) 
                            <E T="03">Exposure to violence (intimate partner violence).</E>
                             Enable exposure to violence (intimate partner violence) to be recorded in accordance with the standard specified in § 170.207(p)(8) and whether a patient declines to specify exposure to violence (intimate partner violence).
                        </P>
                        <P>
                            (b) 
                            <E T="03">Care coordination</E>
                            —(1) 
                            <E T="03">Transitions of care</E>
                            —(i) 
                            <E T="03">Send and receive via edge protocol.</E>
                             (A) Send transition of care/referral summaries through a method that conforms to the standard specified in § 170.202(d) and that leads to such summaries being processed by a service that has implemented the standard specified in § 170.202(a)(2); and
                        </P>
                        <P>(B) Receive transition of care/referral summaries through a method that conforms to the standard specified in § 170.202(d) from a service that has implemented the standard specified in § 170.202(a)(2).</P>
                        <P>
                            (C) 
                            <E T="03">XDM processing.</E>
                             Receive and make available the contents of a XDM package formatted in accordance with the standard adopted in § 170.205(p)(1) when the technology is also being certified using an SMTP-based edge protocol.
                        </P>
                        <P>
                            (ii) 
                            <E T="03">Validate and display</E>
                            —(A) 
                            <E T="03">Validate C-CDA conformance—system performance.</E>
                             Demonstrate the ability to detect valid and invalid transition of care/referral summaries received and formatted in accordance with the standards specified in § 170.205(a)(3) through (5) for the Continuity of Care Document, Referral Note, and (inpatient setting only) Discharge Summary document templates. This includes the ability to:
                        </P>
                        <P>
                            (
                            <E T="03">1</E>
                            ) Parse each of the document types.
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) Detect errors in corresponding “document-templates,” “section-templates,” and “entry-templates,” including invalid vocabulary standards and codes not specified in the standards adopted in § 170.205(a)(3) through (5).
                        </P>
                        <P>
                            (
                            <E T="03">3</E>
                            ) Identify valid document-templates and process the data elements required in the corresponding section-templates and entry-templates from the standards adopted in § 170.205(a)(3) through (5).
                        </P>
                        <P>
                            (
                            <E T="03">4</E>
                            ) Correctly interpret empty sections and null combinations.
                        </P>
                        <P>
                            (
                            <E T="03">5</E>
                            ) Record errors encountered and allow a user through at least one of the following ways to:
                        </P>
                        <P>
                            (
                            <E T="03">i</E>
                            ) Be notified of the errors produced.
                        </P>
                        <P>
                            (
                            <E T="03">ii</E>
                            ) Review the errors produced.
                        </P>
                        <P>
                            (B) 
                            <E T="03">Display.</E>
                             Display in human readable format the data included in transition of care/referral summaries received and formatted according to the standards specified in § 170.205(a)(3) through (5).
                        </P>
                        <P>
                            (C) 
                            <E T="03">Display section views.</E>
                             Allow for the individual display of each section (and the accompanying document header information) that is included in a transition of care/referral summary received and formatted in accordance with the standards adopted in § 170.205(a)(3) through (5) in a manner that enables the user to:
                        </P>
                        <P>
                            (
                            <E T="03">1</E>
                            ) Directly display only the data within a particular section;
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) Set a preference for the display order of specific sections; and
                        </P>
                        <P>
                            (
                            <E T="03">3</E>
                            ) Set the initial quantity of sections to be displayed.
                        </P>
                        <P>
                            (iii) 
                            <E T="03">Create.</E>
                             Enable a user to create a transition of care/referral summary formatted in accordance with the standard specified in § 170.205(a)(3) through (5) using the Continuity of Care Document, Referral Note, and (inpatient setting only) Discharge Summary document templates that includes, at a minimum:
                        </P>
                        <P>
                            (A) 
                            <E T="03">USCDI.</E>
                             (
                            <E T="03">1</E>
                            ) The data classes expressed in the standards in § 170.213 and in accordance with § 170.205(a)(4) and (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) and (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>
                        <P>
                            (
                            <E T="03">3</E>
                            ) The following data classes:
                        </P>
                        <P>
                            (
                            <E T="03">i</E>
                            ) 
                            <E T="03">Assessment and plan of treatment.</E>
                             In accordance with the “Assessment and Plan Section (V2)” of the standard specified in § 170.205(a)(4); or in accordance with the “Assessment Section (V2)” and “Plan of Treatment Section (V2)” of the standard specified in § 170.205(a)(4).
                        </P>
                        <P>
                            (
                            <E T="03">ii</E>
                            ) 
                            <E T="03">Goals.</E>
                             In accordance with the “Goals Section” of the standard specified in § 170.205(a)(4).
                        </P>
                        <P>
                            (
                            <E T="03">iii</E>
                            ) 
                            <E T="03">Health concerns.</E>
                             In accordance with the “Health Concerns Section” of the standard specified in § 170.205(a)(4).
                        </P>
                        <P>
                            (
                            <E T="03">iv</E>
                            ) 
                            <E T="03">Unique device identifier(s) for a patient's implantable device(s).</E>
                             In accordance with the “Product Instance” in the “Procedure Activity Procedure Section” of the standard specified in § 170.205(a)(4).
                        </P>
                        <P>
                            (B) 
                            <E T="03">Encounter diagnoses.</E>
                             Formatted according to at least one of the following standards:
                        </P>
                        <P>
                            (
                            <E T="03">1</E>
                            ) The standard specified in § 170.207(i).
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) At a minimum, at least one of the versions of SNOMED CT U.S. Edition specified in § 170.207(a).
                        </P>
                        <P>
                            (C) 
                            <E T="03">Additional data.</E>
                             Cognitive status.
                        </P>
                        <P>
                            (D) 
                            <E T="03">Additional data.</E>
                             Functional status.
                        </P>
                        <P>
                            (E) 
                            <E T="03">Ambulatory setting only.</E>
                             The reason for referral; and referring or transitioning provider's name and office contact information.
                        </P>
                        <P>
                            (F) 
                            <E T="03">Inpatient setting only.</E>
                             Discharge instructions.
                        </P>
                        <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>
                        <P>
                            (
                            <E T="03">1</E>
                            ) 
                            <E T="03">Date of birth constraint—</E>
                            (
                            <E T="03">i</E>
                            )
                            <E T="03">Year, month, and day.</E>
                             The year, month and day of birth must be present for a date of birth. The technology must include a null value when the date of birth is unknown.
                        </P>
                        <P>
                            (
                            <E T="03">ii</E>
                            ) 
                            <E T="03">Optional.</E>
                             When the hour, minute, and second are associated with a date of birth the technology must demonstrate that the correct time zone offset is included.
                            <PRTPAGE P="63775"/>
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) 
                            <E T="03">Phone number constraint.</E>
                             Represent phone number (home, business, cell) in accordance with the standards adopted in § 170.207(q)(1). All phone numbers must be included when multiple phone numbers are present.
                        </P>
                        <P>
                            (
                            <E T="03">3</E>
                            ) 
                            <E T="03">Sex constraint.</E>
                             Represent sex with at least one of the versions of the standards adopted in § 170.207(n).
                        </P>
                        <P>(H) On and after January 1, 2028, imaging links.</P>
                        <P>
                            (2) 
                            <E T="03">Clinical Information Reconciliation and Incorporation</E>
                            —For the time period up to and including December 31, 2027, a Health IT Module must meet either the requirements in paragraphs (b)(2)(i), (ii), (iii) and (vii) of this section; or the requirements in paragraphs (b)(2)(iv), (v), (vi) and (vii) of this section. On and after January 1, 2028, a Health IT Module must meet the requirements in paragraphs (b)(2)(iv), (v), (vi) and (vii).
                        </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), and (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) 
                            <E T="03">Reconciliation.</E>
                             Enable a user to reconcile the data that represent a patient's active medication list, allergies and intolerance list, and problem list as follows. For each list type:
                        </P>
                        <P>
                            (A) Simultaneously display (
                            <E T="03">i.e.,</E>
                             in a single view) the data from at least two sources in a manner that allows a user to view the data and their attributes, which must include, at a minimum, the source and last modification date.
                        </P>
                        <P>(B) Enable a user to create a single reconciled list of each of the following: Medications; Allergies and Intolerances; and problems.</P>
                        <P>(C) Enable a user to review and validate the accuracy of a final set of data.</P>
                        <P>(D) Upon a user's confirmation, automatically update the list, and incorporate the following data expressed according to the specified standards:</P>
                        <P>
                            (
                            <E T="03">1</E>
                            ) 
                            <E T="03">Medications.</E>
                             At a minimum, the version of the standard specified in § 170.213;
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) 
                            <E T="03">Allergies and intolerance.</E>
                             At a minimum, the version of the standard specified in § 170.213; and
                        </P>
                        <P>
                            (
                            <E T="03">3</E>
                            ) 
                            <E T="03">Problems.</E>
                             At a minimum, the version of the standard specified in § 170.213. (iv) 
                            <E T="03">General requirements.</E>
                             Upon receipt of a transition of care/referral summary formatted in accordance with the standards adopted in § 170.205(a)(3), (4), and (6), a Health IT Module must demonstrate that the transition of care/referral summary received can be properly matched to the correct patient according to the standards adopted in § 170.205(a)(3), (4), and (6), enable a user to reconcile and incorporate by default each data element in at least one of the versions of the USCDI standard specified in § 170.213 according to paragraph (b)(2)(v) of this section, and execute all reconciliation and incorporation rules that are enabled and/or configured by an organization within their deployed technology according to paragraph (b)(2)(vi) of this section.
                        </P>
                        <P>
                            (v) 
                            <E T="03">User reconciliation.</E>
                             Enable a user to reconcile data as follows. For each data element included in at least one of the versions of the USCDI standard in § 170.213:
                        </P>
                        <P>
                            (A) Simultaneously display (
                            <E T="03">i.e.,</E>
                             in a single view) the data from at least two sources in a manner that allows a user to view the data and their attributes, which must include, at a minimum, the source and last date.
                        </P>
                        <P>(B) Enable a user to create a single reconciled list of each of the data.</P>
                        <P>(C) Enable a user to review and validate the accuracy of a final set of data.</P>
                        <P>(D) Upon a user's confirmation, automatically update and incorporate the data.</P>
                        <P>
                            (vi) 
                            <E T="03">User configuration.</E>
                             Enable a user to set individual or organizational rules that allow automatic reconciliation and incorporation for each of the data classes included in at least one of the versions of the USCDI standard specified in § 170.213, including functionality that allows the user to select trusted data and trusted sources for automatic reconciliation and incorporation.
                        </P>
                        <P>
                            (vii) 
                            <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:
                        </P>
                        <P>(A) The standard specified in § 170.205(a)(4) using the Continuity of Care Document template and,</P>
                        <P>(B) The standard(s) specified in § 170.205(a)(5) for the time period up to and including December 31, 2025; or § 170.205(a)(6).</P>
                        <P>
                            (3) 
                            <E T="03">Electronic prescribing.</E>
                             (i) [Reserved]
                        </P>
                        <P>(ii) For technology certified subsequent to June 30, 2020:</P>
                        <P>(A) For the time period up to and including December 31, 2027, enable a user to perform the following prescription-related electronic transactions in accordance with the standards specified in § 170.205(b)(1) or (2); at least one of the versions of the standard adopted in § 170.207(d)(1); and the standard adopted in § 170.207(d)(2) if using the standard in § 170.205(b)(2). On and after January 1, 2028, enable a user to perform the following prescription-related electronic transactions in accordance with the standards specified in § 170.205(b)(2) and (d)(1) and (2).</P>
                        <P>
                            (
                            <E T="03">1</E>
                            ) New prescriptions (NewRx).
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) Request and respond to change prescriptions (RxChangeRequest, RxChangeResponse).
                        </P>
                        <P>
                            (
                            <E T="03">3</E>
                            ) Request and respond to cancel prescriptions (CancelRx, CancelRxResponse).
                        </P>
                        <P>
                            (
                            <E T="03">4</E>
                            ) Request and respond to renew prescriptions (RxRenewalRequest, RxRenewalResponse).
                        </P>
                        <P>
                            (
                            <E T="03">5</E>
                            ) Receive fill status notifications (RxFill).
                        </P>
                        <P>
                            (
                            <E T="03">6</E>
                            ) [Reserved]
                        </P>
                        <P>
                            (
                            <E T="03">7</E>
                            ) Relay acceptance of a transaction back to the sender (Status).
                        </P>
                        <P>
                            (
                            <E T="03">8</E>
                            ) Respond that there was a problem with the transaction (Error).
                        </P>
                        <P>
                            (
                            <E T="03">9</E>
                            ) Respond that a transaction requesting a return receipt has been received (Verify).
                        </P>
                        <P>
                            (
                            <E T="03">10</E>
                            ) Electronic prior authorization transactions (PAInitiationRequest, PAInitiationResponse, PARequest, PAResponse, PAAppealRequest, PAAppealResponse, PACancelRequest, and PACancelResponse, PANotification). These transactions are required if using the standard in 170.205(b)(2).
                        </P>
                        <P>(B) Enable a user to exchange race and ethnicity information when performing the following prescription-related electronic transactions, if using the standard in § 170.205(b)(2):</P>
                        <P>
                            (
                            <E T="03">1</E>
                            ) Receive fill status notifications (RxFill).
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) Request and respond to change prescriptions (RxChangeRequest, RxChangeResponse).
                        </P>
                        <P>
                            (
                            <E T="03">3</E>
                            ) Request to cancel prescriptions (CancelRx).
                        </P>
                        <P>
                            (
                            <E T="03">4)</E>
                             Request and respond to renew prescriptions (RxRenewalRequest, RxRenewalResponse).
                        </P>
                        <P>
                            (C) For the following prescription-related transactions, the technology 
                            <PRTPAGE P="63776"/>
                            must be able to receive and transmit the reason for prescription using the diagnosis elements: (Diagnosis), (Primary), or (Secondary):
                        </P>
                        <P>
                            (
                            <E T="03">1</E>
                            ) Required transactions:
                        </P>
                        <P>(i) New prescriptions (NewRx).</P>
                        <P>
                            (
                            <E T="03">ii</E>
                            ) Request and respond to change prescriptions (RxChangeRequest, RxChangeResponse).
                        </P>
                        <P>
                            (
                            <E T="03">iii</E>
                            ) Cancel prescriptions (CancelRx).
                        </P>
                        <P>
                            (
                            <E T="03">iv</E>
                            ) Request and respond to renew prescriptions (RxRenewalRequest, RxRenewalResponse).
                        </P>
                        <P>
                            (
                            <E T="03">v</E>
                            ) Receive fill status notifications (RxFill).
                        </P>
                        <P>(vi) [Reserved]</P>
                        <P>(vii) Electronic prior authorization (ePA) transactions (PAInitiationRequest, PAInitiationResponse, PARequest, PAResponse, PAAppealRequest, PAAppealResponse and PACancelRequest, PACancelResponse, PANotification). These transactions are required if using the standard in § 170.205(b)(2).</P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) [Reserved]
                        </P>
                        <P>(D) Enable a user to enter, receive, and transmit structured and codified prescribing instructions in accordance with the standard specified in § 170.205(b)(2). This section is only required if using the standard in § 170.205(b)(2).</P>
                        <P>
                            (E) Limit a user's ability to prescribe all oral liquid medications in only metric standard units of mL (
                            <E T="03">i.e.,</E>
                             not cc).
                        </P>
                        <P>(F) Always insert leading zeroes before the decimal point for amounts less than one and must not allow trailing zeroes after a decimal point when a user prescribes medications.</P>
                        <P>(G) On and after January 1, 2028, meet the requirements specified in paragraph (d)(13)(ii) of this section for user-facing authentication.</P>
                        <P>
                            (4) 
                            <E T="03">Real-time prescription benefit—</E>
                            (i) 
                            <E T="03">Send and receive information.</E>
                             Enable a user to perform the following transactions using the XML format in accordance with at least one of the versions of the standards adopted in both §§ 170.205(c) and 170.207(d)(1), and the standard in § 170.207(d)(2) as follows:
                        </P>
                        <P>(A) Enable a user to request patient-specific prescription benefit information, estimated cost information, and therapeutic alternatives, in accordance with the RTPBRequest transaction.</P>
                        <P>(B) Enable a user to receive patient-specific prescription benefit information, estimated cost information, and therapeutic alternatives in response to a request, in accordance with the RTPBResponse transaction.</P>
                        <P>(C) Enable a user to be notified of errors when there is a problem with a real-time prescription benefit transaction, in accordance with the RTPBError transaction.</P>
                        <P>
                            (ii) 
                            <E T="03">Display.</E>
                             Display to a user in human readable format patient-specific prescription benefit information, estimated cost information, and therapeutic alternatives, in accordance with at least one of the versions of the standard adopted in § 170.205(c).
                        </P>
                        <P>
                            (iii) 
                            <E T="03">Scope.</E>
                             The scope of this criterion is limited to medications and vaccines covered by a pharmacy benefit.
                        </P>
                        <P>(5)-(6) [Reserved]</P>
                        <P>
                            (7) 
                            <E T="03">Security tags—summary of care—send.</E>
                             Enable a user to create a summary record formatted in accordance with the standard adopted in § 170.205(a)(4) that is tagged as restricted and subject to restrictions on re-disclosure according to the standard adopted in § 170.205(o)(1) at the document, section, and entry (data element) level.
                        </P>
                        <P>
                            (8) 
                            <E T="03">Security tags—summary of care—receive.</E>
                             (i) Enable a user to receive a summary record that is formatted in accordance with the standard adopted in § 170.205(a)(4) that is tagged as restricted and subject to restrictions on re-disclosure according to the standard adopted in § 170.205(o)(1) at the document, section, and entry (data element) level; and
                        </P>
                        <P>(ii) Preserve privacy markings to ensure fidelity to the tagging based on consent and with respect to sharing and re-disclosure restrictions.</P>
                        <P>
                            (9) 
                            <E T="03">Care plan.</E>
                             Enable a user to record, change, access, create, and receive care plan information in accordance with:
                        </P>
                        <P>(i) The Care Plan document template, including the Health Status Evaluations and Outcomes Section and Interventions Section (V2), in the standard specified in § 170.205(a)(4); and</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>
                        <P>
                            (10) 
                            <E T="03">Electronic health information export</E>
                            —(i) 
                            <E T="03">Single patient electronic health information export.</E>
                             (A) Enable a user to timely create an export file(s) with all of a single patient's electronic health information that can be stored at the time of certification by the product, of which the Health IT Module is a part.
                        </P>
                        <P>(B) Except as specified in paragraph (b)(10)(i)(F) of this section, a user must be able to execute this capability at any time the user chooses and without subsequent developer assistance to operate.</P>
                        <P>(C) Limit the ability of users who can create export file(s) in at least one of these two ways:</P>
                        <P>
                            (
                            <E T="03">1</E>
                            ) To a specific set of identified users.
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) As a system administrative function.
                        </P>
                        <P>(D) The export file(s) created must be electronic and in a computable format.</P>
                        <P>(E) The publicly accessible hyperlink of the export's format must be included with the exported file(s).</P>
                        <P>(F) A Health IT Module that acts primarily as an intermediary between systems and, through integration, functions without any direct human interaction need not meet the requirement in paragraph (b)(10)(i)(B) of this section, and may satisfy this criterion through a developer-assisted process provided that:</P>
                        <P>
                            (
                            <E T="03">1</E>
                            ) The EHI that the Health IT Module stores or that the Health IT Module causes to be stored is a copy, whether in the same or another format, of EHI also stored by another Health IT Module with which the Health IT Module is integrated; and
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) The developer has not received more than 10 requests for a single patient EHI export from that Health IT Module during the immediately preceding calendar year.
                        </P>
                        <P>
                            (ii) 
                            <E T="03">Patient population electronic health information export.</E>
                             Create an export of all the electronic health information that can be stored at the time of certification by the product, of which the Health IT Module is a part.
                        </P>
                        <P>(A) The export created must be electronic and in a computable format.</P>
                        <P>(B) The publicly accessible hyperlink of the export's format must be included with the exported file(s).</P>
                        <P>
                            (iii) 
                            <E T="03">Documentation.</E>
                             The export format(s) used to support paragraphs (b)(10)(i) and (ii) of this section must be kept up-to-date.
                        </P>
                        <P>
                            (11) 
                            <E T="03">Decision support interventions</E>
                            —(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.
                            <PRTPAGE P="63777"/>
                        </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.</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>
                            ) through (
                            <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">iv</E>
                            ) 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>
                            ) through (
                            <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 
                            <PRTPAGE P="63778"/>
                            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, 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) 
                            <E T="03">Data.</E>
                             (A) Taxpayer Identification Number.
                        </P>
                        <P>(B) National Provider Identifier.</P>
                        <P>(C) Provider type in accordance with, at a minimum, at least one of the versions of the standard specified in § 170.207(r).</P>
                        <P>(D) Practice site address.</P>
                        <P>(E) Patient insurance in accordance with at least one of the versions of the standard specified in § 170.207(s).</P>
                        <P>(F) Patient age.</P>
                        <P>(G) Patient sex in accordance with the at least one of the versions of the standard specified in § 170.207(n).</P>
                        <P>(H) Patient race and ethnicity in accordance with, at a minimum, at least one of the versions of the standard specified in § 170.207(f)(1) and at least one of the versions of the standard specified in § 170.207(f)(2).</P>
                        <P>(I) Patient problem list data in accordance with, at a minimum, at least one of the versions of SNOMED CT U.S. Edition specified in § 170.207(a).</P>
                        <STARS/>
                        <P>
                            (d) 
                            <E T="03">Privacy and security</E>
                            —(1) 
                            <E T="03">Authentication, access control, and authorization.</E>
                             (i) Verify against a unique identifier(s) (
                            <E T="03">e.g.,</E>
                             username or number) that a user seeking access to electronic health information is the one claimed; and
                        </P>
                        <P>(ii) Establish the type of access to electronic health information a user is permitted based on the unique identifier(s) provided in paragraph (d)(1)(i) of this section, and the actions the user is permitted to perform with the technology.</P>
                        <P>
                            (2) 
                            <E T="03">Auditable events and tamper-resistance</E>
                            —(i) 
                            <E T="03">Record actions.</E>
                             Technology must be able to:
                        </P>
                        <P>(A) Record actions related to electronic health information in accordance with the standard specified in § 170.210(e)(1);</P>
                        <P>(B) Record the audit log status (enabled or disabled) in accordance with the standard specified in § 170.210(e)(2) unless it cannot be disabled by any user; and</P>
                        <P>(C) Record the encryption status (enabled or disabled) of electronic health information locally stored on end-user devices by technology in accordance with the standard specified in § 170.210(e)(3) unless the technology prevents electronic health information from being locally stored on end-user devices (see paragraph (d)(7) of this section).</P>
                        <P>
                            (ii) 
                            <E T="03">Default setting.</E>
                             Technology must be set by default to perform the capabilities specified in paragraph (d)(2)(i)(A) of this section and, where applicable, paragraphs (d)(2)(i)(B) and (C) of this section.
                        </P>
                        <P>
                            (iii) 
                            <E T="03">When disabling the audit log is permitted.</E>
                             For each capability specified in paragraphs (d)(2)(i)(A) through (C) of this section that technology permits to be disabled, the ability to do so must be restricted to a limited set of users.
                        </P>
                        <P>
                            (iv) 
                            <E T="03">Audit log protection.</E>
                             Actions and statuses recorded in accordance with paragraph (d)(2)(i) of this section must not be capable of being changed, overwritten, or deleted by the technology.
                        </P>
                        <P>
                            (v) 
                            <E T="03">Detection.</E>
                             Technology must be able to detect whether the audit log has been altered.
                        </P>
                        <P>
                            (3) 
                            <E T="03">Audit report(s).</E>
                             Enable a user to create an audit report for a specific time period and to sort entries in the audit log according to each of the data specified in the standards in § 170.210(e).
                        </P>
                        <P>
                            (4) 
                            <E T="03">Amendments.</E>
                             Enable a user to select the record affected by a patient's request for amendment and perform the capabilities specified in paragraph (d)(4)(i) or (ii) of this section.
                        </P>
                        <P>
                            (i) 
                            <E T="03">Accepted amendment.</E>
                             For an accepted amendment, append the amendment to the affected record or include a link that indicates the amendment's location.
                        </P>
                        <P>
                            (ii) 
                            <E T="03">Denied amendment.</E>
                             For a denied amendment, at a minimum, append the request and denial of the request in at least one of the following ways:
                        </P>
                        <P>(A) To the affected record.</P>
                        <P>(B) Include a link that indicates this information's location.</P>
                        <P>
                            (5) 
                            <E T="03">Automatic access time-out.</E>
                             (i) Automatically stop user access to health information after a predetermined period of inactivity.
                        </P>
                        <P>(ii) Require user authentication in order to resume or regain the access that was stopped.</P>
                        <P>
                            (6) 
                            <E T="03">Emergency access.</E>
                             Permit an identified set of users to access electronic health information during an emergency.
                        </P>
                        <P>
                            (7) 
                            <E T="03">Health IT encryption.</E>
                             For the time period up to and including December 31, 2025, a Health IT Module must meet the requirements in paragraphs (d)(7)(i), (iv), and (v) of this section or meet the requirements in (d)(7)(ii), (iii), (iv), and (v) of this section. On and after January 1, 2026, a Health IT Module must meet the requirements in (d)(7)(ii), (iii), (iv), and (v).
                        </P>
                        <P>
                            (i) 
                            <E T="03">End-user device encryption of electronic health information.</E>
                             The requirements specified in either paragraph (d)(7)(i)(A) or (B) of this section must be met.
                        </P>
                        <P>(A) Technology that is designed to locally store electronic health information on end-user devices must encrypt the electronic health information stored on such devices after use of the technology on those devices stops.</P>
                        <P>(B) Technology is designed to prevent electronic health information from being locally stored on end-user devices after use of the technology on those devices stops.</P>
                        <P>
                            (ii) 
                            <E T="03">End-user device encryption of personally identifiable information.</E>
                             The requirements specified in either paragraph (d)(7)(ii)(A) or (B) of this section must be met.
                        </P>
                        <P>(A) Technology that is designed to locally store personally identifiable information on end-user devices must encrypt the personally identifiable information.</P>
                        <P>(B) Technology is designed to prevent personally identifiable information from being locally stored on end-user devices after use of the technology on those devices stops.</P>
                        <P>
                            (iii) 
                            <E T="03">Server encryption.</E>
                             Technology that is designed to store personally identifiable information must encrypt the stored personally identifiable information after use of the technology on those servers stops.
                        </P>
                        <P>
                            (iv) 
                            <E T="03">Encryption standard.</E>
                             Information that is encrypted to meet paragraph (d)(7)(i)(A), (d)(7)(ii)(A), or (d)(7)(iii) of 
                            <PRTPAGE P="63779"/>
                            this section must be encrypted in accordance with at least one version of the standard specified in § 170.210(a).
                        </P>
                        <P>
                            (v) 
                            <E T="03">Default settings.</E>
                             (A) Technology that is designed to meet paragraph (d)(7)(i)(A), (d)(7)(ii)(A), or (d)(7)(iii) of this section must be set by default to perform those capabilities.
                        </P>
                        <P>(B) Unless the default configurations for the capabilities defined in paragraphs (d)(7)(i)(A), (d)(7)(ii)(A), and (d)(7)(iii) of this section cannot be disabled by any user, the ability to change these configurations must be restricted to a limited set of identified users.</P>
                        <P>
                            (8) 
                            <E T="03">Integrity.</E>
                             (i) Create a message digest in accordance with the standard specified in § 170.210(c)(2).
                        </P>
                        <P>(ii) Verify in accordance with the standard specified in § 170.210(c)(2) upon receipt of electronically exchanged health information that such information has not been altered.</P>
                        <P>
                            (9) 
                            <E T="03">Trusted connection.</E>
                             Establish a trusted connection using one of the following methods:
                        </P>
                        <P>
                            (i) 
                            <E T="03">Message-level.</E>
                             Encrypt and integrity protect message contents in accordance with at least one version of the standard specified in § 170.210(a) and the standard specified in § 170.210(c)(2).
                        </P>
                        <P>
                            (ii) 
                            <E T="03">Transport-level.</E>
                             Use a trusted connection in accordance with at least one version of the standard specified in § 170.210(a) and the standard specified in § 170.210(c)(2).
                        </P>
                        <P>
                            (10) 
                            <E T="03">Auditing actions on health information.</E>
                             (i) By default, be set to record actions related to electronic health information in accordance with the standard specified in § 170.210(e)(1).
                        </P>
                        <P>(ii) If technology permits auditing to be disabled, the ability to do so must be restricted to a limited set of users.</P>
                        <P>(iii) Actions recorded related to electronic health information must not be capable of being changed, overwritten, or deleted by the technology.</P>
                        <P>(iv) Technology must be able to detect whether the audit log has been altered.</P>
                        <P>
                            (11) 
                            <E T="03">Accounting of disclosures.</E>
                             Record disclosures made for treatment, payment, and health care operations in accordance with the standard specified in § 170.210(d).
                        </P>
                        <P>
                            (12) 
                            <E T="03">Protect stored authentication credentials.</E>
                             For the time period up to and including December 31, 2025, a Health IT Module must meet either the requirements specified in (d)(12)(i) or (ii) of this section. On and after January 1, 2026, a Health IT Module must meet the requirements in (d)(12)(ii) of this section.
                        </P>
                        <P>(i) Health IT developers must make one of the following attestations and may provide the specified accompanying information where applicable:</P>
                        <P>(A) Yes—the Health IT Module encrypts stored authentication credentials in accordance with at least one of the standards adopted in § 170.210(a).</P>
                        <P>(B) No—the Health IT Module does not encrypt stored authentication credentials. When attesting “no,” the health IT developer may explain why the Health IT Module does not support encrypting stored authentication credentials.</P>
                        <P>(ii) A Health IT Module designed to store authentication credentials must protect the confidentiality and integrity of its stored authentication credentials according to at least one of the following standards:</P>
                        <P>(A) Encryption and decryption in accordance with at least one of the standards specified in § 170.210(a).</P>
                        <P>(B) Hashing in accordance with the standard specified in § 170.210(c)(2).</P>
                        <P>
                            (13) 
                            <E T="03">Multi-factor authentication.</E>
                             For the time period up to and including December 31, 2027, a Health IT Module must meet either the requirements in paragraph (d)(13)(i) or (ii) of this section. On and after January 1, 2028, a Health IT Module must meet the requirements specified in paragraph (d)(13)(ii).
                        </P>
                        <P>(i) Health IT developers must make one of the following attestations and, as applicable, provide the specified accompanying information:</P>
                        <P>(A) Yes—the Health IT Module supports the authentication, through multiple elements, of the user's identity with the use of industry-recognized standards. When attesting “yes,” the health IT developer must describe the use cases supported.</P>
                        <P>(B) No—the Health IT Module does not support authentication, through multiple elements, of the user's identity with the use of industry-recognized standards. When attesting “no,” the health IT developer may explain why the Health IT Module does not support authentication, through multiple elements, of the user's identity with the use of industry-recognized standards.</P>
                        <P>(ii) Using industry recognized standards, the Health IT Module must:</P>
                        <P>(A) Support authentication, through multiple elements, of the user's identity.</P>
                        <P>(B) Enable a user to configure, enable, and disable the multi-factor authentication capabilities defined in paragraphs (d)(13)(ii) introductory text and (d)(13)(ii)(A) of this section.</P>
                        <P>
                            (e) 
                            <E T="03">Patient engagement</E>
                            —(1) 
                            <E T="03">View, download, and transmit to 3rd party.</E>
                             (i) Patients (and their authorized representatives) must be able to use internet-based technology to view, download, and transmit their health information to a 3rd party in the manner specified below. Such access must be consistent and in accordance with the standard adopted in § 170.204(a)(1) and may alternatively be demonstrated in accordance with the standard specified in § 170.204(a)(2).
                        </P>
                        <P>
                            (A) 
                            <E T="03">View.</E>
                             Patients (and their authorized representatives) must be able to use health IT to view, at a minimum, the following data:
                        </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 (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 (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>
                        <P>
                            (
                            <E T="03">3</E>
                            ) The following data classes:
                        </P>
                        <P>
                            (
                            <E T="03">i</E>
                            ) 
                            <E T="03">Assessment and plan of treatment.</E>
                             In accordance with the “Assessment and Plan Section (V2)” of the standard specified in § 170.205(a)(4); or in accordance with the “Assessment Section (V2)” and “Plan of Treatment Section (V2)” of the standard specified in § 170.205(a)(4).
                        </P>
                        <P>
                            (
                            <E T="03">ii</E>
                            ) 
                            <E T="03">Goals.</E>
                             In accordance with the “Goals Section” of the standard specified in § 170.205(a)(4).
                        </P>
                        <P>
                            (
                            <E T="03">iii</E>
                            ) 
                            <E T="03">Health concerns.</E>
                             In accordance with the “Health Concerns Section” of the standard specified in § 170.205(a)(4).
                        </P>
                        <P>
                            (
                            <E T="03">iv</E>
                            ) 
                            <E T="03">Unique device identifier(s) for a patient's implantable device(s).</E>
                             In accordance with the “Product Instance” in the “Procedure Activity Procedure Section” of the standards specified in § 170.205(a)(4).
                        </P>
                        <P>
                            (
                            <E T="03">4</E>
                            ) Ambulatory setting only: Provider's name and office contact information.
                        </P>
                        <P>
                            (
                            <E T="03">5</E>
                            ) Inpatient setting only: Admission and discharge dates and locations; discharge instructions; and reason(s) for hospitalization.
                        </P>
                        <P>
                            (
                            <E T="03">6</E>
                            ) Laboratory test report(s): Laboratory test report(s), including:
                        </P>
                        <P>
                            (
                            <E T="03">i</E>
                            ) The information for a test report as specified all the data specified in 42 CFR 493.1291(c)(1) through (7);
                        </P>
                        <P>
                            (
                            <E T="03">ii</E>
                            ) The information related to reference intervals or normal values as specified in 42 CFR 493.1291(d); and
                        </P>
                        <P>
                            (
                            <E T="03">iii</E>
                            ) The information for corrected reports as specified in 42 CFR 493.1291(k)(2).
                            <PRTPAGE P="63780"/>
                        </P>
                        <P>
                            (
                            <E T="03">7</E>
                            ) Diagnostic image report(s).
                        </P>
                        <P>
                            (
                            <E T="03">8</E>
                            ) 
                            <E T="03">Diagnostic Images.</E>
                             On and after January 1, 2028, support for both diagnostic quality images and reduced quality images.
                        </P>
                        <P>
                            (B) 
                            <E T="03">Download.</E>
                             (
                            <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>
                        <P>
                            <E T="03">(i)</E>
                             Ambulatory setting only. All of the data specified in paragraphs (e)(1)(i)(A)(
                            <E T="03">1</E>
                            ), (
                            <E T="03">2</E>
                            ), (
                            <E T="03">4</E>
                            ), and (
                            <E T="03">5</E>
                            ) of this section, and, on and after January 1, 2028, an imaging link to the data specified in paragraph (e)(1)(i)(A)(
                            <E T="03">8</E>
                            ) of this section.
                        </P>
                        <P>
                            <E T="03">(ii)</E>
                             Inpatient setting only. All of the data specified in paragraphs (e)(1)(i)(A)(
                            <E T="03">1</E>
                            ) and (
                            <E T="03">3</E>
                            ) through (5) of this section, and, on and after January 1, 2028, an imaging link to the data specified in paragraph (e)(1)(i)(A)(
                            <E T="03">8</E>
                            ) of this section.
                        </P>
                        <P>
                            (
                            <E T="03">3</E>
                            ) Inpatient setting only: Patients (and their authorized representatives) must be able to download transition of care/referral summaries that were created as a result of a transition of care (pursuant to the capability expressed in the certification criterion specified in paragraph (b)(1) of this section).
                        </P>
                        <P>
                            (
                            <E T="03">4</E>
                            ) On and after January 1, 2028, patients (and their authorized representatives) must be able to use technology to download both diagnostic quality and reduced quality images.
                        </P>
                        <P>
                            (C) 
                            <E T="03">Transmit to third party.</E>
                             Patients (and their authorized representatives) must be able to:
                        </P>
                        <P>
                            (
                            <E T="03">1</E>
                            ) Transmit the ambulatory summary or inpatient summary (as applicable to the health IT setting for which certification is requested) created in paragraph (e)(1)(i)(B)(
                            <E T="03">2</E>
                            ) of this section in accordance with both of the following ways:
                        </P>
                        <P>
                            (
                            <E T="03">i</E>
                            ) Email transmission to any email address; and
                        </P>
                        <P>
                            (
                            <E T="03">ii</E>
                            ) An encrypted method of electronic transmission.
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) Inpatient setting only: Transmit transition of care/referral summaries (as a result of a transition of care/referral as referenced by (e)(1)(i)(B)(
                            <E T="03">3</E>
                            ) of this section) selected by the patient (or their authorized representative) in both of the ways referenced (e)(1)(i)(C)(
                            <E T="03">1</E>
                            )(
                            <E T="03">i</E>
                            ) and (
                            <E T="03">ii</E>
                            ) of this section).
                        </P>
                        <P>
                            (D) 
                            <E T="03">Timeframe selection.</E>
                             With respect to the data available to view, download, and transmit as referenced paragraphs (e)(1)(i)(A) through (C) of this section, patients (and their authorized representatives) must be able to:
                        </P>
                        <P>
                            (
                            <E T="03">1</E>
                            ) Select data associated with a specific date (to be viewed, downloaded, or transmitted); and
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) Select data within an identified date range (to be viewed, downloaded, or transmitted).
                        </P>
                        <P>
                            (ii) 
                            <E T="03">Activity history log.</E>
                             (A) When any of the capabilities included in paragraphs (e)(1)(i)(A) through (C) of this section are used, the following information must be recorded and made accessible to the patient (or his/her authorized representative):
                        </P>
                        <P>
                            (
                            <E T="03">1</E>
                            ) The action(s) (
                            <E T="03">i.e.,</E>
                             view, download, transmission) that occurred;
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) The date and time each action occurred in accordance with the standard specified in § 170.210(g);
                        </P>
                        <P>
                            (
                            <E T="03">3</E>
                            ) The user who took the action; and
                        </P>
                        <P>
                            (
                            <E T="03">4</E>
                            ) Where applicable, the addressee to whom an ambulatory summary or inpatient summary was transmitted.
                        </P>
                        <P>(B) [Reserved]</P>
                        <P>
                            (iii) 
                            <E T="03">Multi-factor authentication.</E>
                             On and after January 1, 2028, meet the requirements specified in § 170.315(d)(13)(ii) for patient facing authentication.
                        </P>
                        <P>(2) [Reserved]</P>
                        <P>
                            (3) 
                            <E T="03">Patient health information capture.</E>
                             Enable a user to:
                        </P>
                        <P>(i) Identify, record, and access information directly and electronically shared by a patient (or authorized representative).</P>
                        <P>(ii) Reference and link to patient health information documents.</P>
                        <P>
                            (f) 
                            <E T="03">Public health</E>
                            —(1) 
                            <E T="03">Immunization registries—bi-directional exchange.</E>
                             For the time period up to and including December 31, 2026, a Health IT Module must meet either the requirements specified in paragraph (f)(1)(i) or in paragraphs (f)(1)(ii) and (iii) of this section. On and after January 1, 2027, a Health IT Module must meet the requirements specified in paragraphs (f)(1)(ii) and (iii) of this section.
                        </P>
                        <P>(i) Create immunization information for electronic transmission in accordance with paragraphs (f)(1)(i)(A) through (C) of this section and enable a user to request, access, and display a patient's evaluated immunization history and the immunization forecast from an immunization registry in accordance with the standard in § 170.205(e)(4).</P>
                        <P>(A) The standard and applicable implementation specifications specified in § 170.205(e)(4).</P>
                        <P>(B) At a minimum, the version of the standard specified in § 170.207(e)(5) for historical vaccines.</P>
                        <P>(C) At a minimum, the version of the standard specified in § 170.207(e)(6) for administered vaccines.</P>
                        <P>(ii) Enable a user to engage in bi-directional immunization information exchange including to:</P>
                        <P>
                            (A) Create immunization information for electronic transmission and support request, access, and display in accordance with the standards in paragraphs (f)(1)(ii)(A)(
                            <E T="03">1</E>
                            ) through (
                            <E T="03">3</E>
                            ) of this section;
                        </P>
                        <P>
                            (
                            <E T="03">1</E>
                            ) At least one of the versions of the standard and applicable implementation specifications specified in § 170.205(e).
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) At a minimum, the version of the standard specified in § 170.207(e)(5) for historical vaccines.
                        </P>
                        <P>
                            (
                            <E T="03">3</E>
                            ) At a minimum, the version of the standard specified in § 170.207(e)(6) for administered vaccines.
                        </P>
                        <P>(B) Request, access, and display a patient's evaluated immunization history and the immunization forecast from an immunization registry in accordance with at least one of the versions of the standard in § 170.205(e); and</P>
                        <P>(C) Receive incoming patient-level immunization-specific query or request from external systems and respond in accordance with paragraph (f)(1)(ii)(A) of this section.</P>
                        <P>(iii) Receive incoming patient-level immunization-specific query or request from external systems and respond.</P>
                        <P>
                            (2) 
                            <E T="03">Syndromic surveillance—Transmission to public health agencies.</E>
                             Create syndrome-based public health surveillance information for electronic transmission in accordance with at least one of the versions of the standards (and applicable implementation specifications) specified in § 170.205(d).
                        </P>
                        <P>
                            (3) 
                            <E T="03">Reportable laboratory results—Transmission to public health agencies—and Laboratory Orders—Receive and validate.</E>
                             For the time period up to and including December 31, 2027, a Health IT Module must meet either the requirements specified in paragraph (f)(3)(i) or (ii) of this section. On and after January 1, 2028, a Health IT Module must meet the requirements specified in paragraph (f)(3)(ii) of this section.
                        </P>
                        <P>
                            (i) Create reportable laboratory tests and values/results for electronic 
                            <PRTPAGE P="63781"/>
                            transmission in accordance with paragraphs (f)(3)(i)(A) and (B) of this section.
                        </P>
                        <P>(A) At least one of the standards specified in § 170.205(g).</P>
                        <P>(B) At a minimum, at least one of the versions of SNOMED CT U.S. Edition specified in § 170.207(a), at least one of the versions of LOINC specified in § 170.207(c), and at least one of the versions of the Unified Code for Units of Measure standard specified in § 170.207(m).</P>
                        <P>(ii) Create and transmit reportable laboratory values/results and receive and validate reportable laboratory orders in accordance with paragraphs (f)(3)(ii)(A) through (C) of this section.</P>
                        <P>(A) Create and transmit reportable laboratory information according to at least one of the standards specified in § 170.205(g).</P>
                        <P>(B) Receive laboratory test orders formatted in accordance with the standard specified in § 170.205(g)(2) and validate conformance. That is, demonstrate the ability to detect valid and invalid electronic reportable laboratory orders received and formatted in accordance with the standard specified in § 170.205(g)(2). The Health IT Module must include the capability to:</P>
                        <P>
                            (
                            <E T="03">1</E>
                            ) Identify valid electronic reportable laboratory orders received and process the data elements required for the standard specified in § 170.205(g)(2).
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) Correctly interpret empty sections and null combinations;
                        </P>
                        <P>
                            (
                            <E T="03">3</E>
                            ) Detect errors in laboratory information received including invalid vocabulary standards and codes not specified in the standard specified in § 170.205(g)(2);
                        </P>
                        <P>
                            (
                            <E T="03">4</E>
                            ) Record errors encountered and allow a user through at least one method to:
                        </P>
                        <P>
                            (
                            <E T="03">i</E>
                            ) Be notified of the errors produced;
                        </P>
                        <P>
                            (
                            <E T="03">ii</E>
                            ) Review the errors produced; and,
                        </P>
                        <P>
                            (
                            <E T="03">iii</E>
                            ) Store or maintain error records for audit or other follow up action.
                        </P>
                        <P>
                            (
                            <E T="03">5</E>
                            ) 
                            <E T="03">Parse and filter.</E>
                             Enable a user to parse and filter electronic laboratory test orders validated in accordance with paragraph (f)(3)(ii) of this section at a minimum for any data element identified as “mandatory” or “must support” in the Public Health Profile within the IG according to the standard specified in § 170.205(g)(3).
                        </P>
                        <P>(C) Create reportable laboratory test values/results for electronic transmission in accordance with the Public Health Profile within the standard specified in § 170.205(g)(3), and, at a minimum, at least one of the versions of SNOMED CT U.S. Edition specified in § 170.207(a), at least one of the LOINC standard versions specified in § 170.207(c), and at least one of the versions of the Unified Code for Units of Measure standard specified in § 170.207(m).</P>
                        <P>
                            (4) 
                            <E T="03">Cancer registry reporting—transmission to public health agencies.</E>
                             For the time period up to and including December 31, 2027, a Health IT Module must meet either the requirements specified in paragraph (f)(4)(i) or the requirements specified in paragraph (f)(4)(ii) of this section. On and after January 1, 2028, a Health IT Module must meet the requirements specified in paragraph (f)(4)(ii) of this section.
                        </P>
                        <P>(i) Create cancer case information for electronic transmission in accordance with paragraphs (f)(4)(i)(A) and (B) of this section.</P>
                        <P>(A) The standard (and applicable implementation specifications) specified in § 170.205(i)(2).</P>
                        <P>(B) At a minimum, at least one of the versions of SNOMED CT U.S. Edition specified in § 170.207(a) and at least one of the LOINC standard versions specified in § 170.207(c).</P>
                        <P>(ii) Create cancer case information for electronic transmission in accordance with either paragraph (i)(A) or (B) of this section; and in accordance with paragraph (i)(C) of this section.</P>
                        <P>(A) The “Central Cancer Registry Reporting Bundle” and accompanying profiles according to the standard specified in § 170.205(i)(3). All data elements indicated as “mandatory” and “must support” within the IG by the standards and implementation specifications must be supported. Including support for the requirements described in the “Central Cancer Registry Reporting EHR Capability Statement.”</P>
                        <P>(B) The standard (and applicable implementation specifications) specified in § 170.205(i)(2) and, at a minimum, at least one of the versions of SNOMED CT U.S. Edition specified in § 170.207(a) and at least one of the LOINC standard versions specified in § 170.207(c).</P>
                        <P>(C) The “US Pathology Exchange Bundle” and accompanying profiles according to the implementation specification adopted in § 170.205(i)(4). All data elements indicated as “mandatory” and “must support” within the IG by the standards and implementation specifications must be supported. Including support for the requirements described in the “Central Cancer Registry Reporting Pathology EHR Capability Statement.”</P>
                        <P>
                            (5) 
                            <E T="03">Electronic case reporting—transmission to public health agencies.</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) 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 (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>
                            ) For the period up to and including December 31, 2027, the HL7 CDA eICR IG in § 170.205(t)(2). Adoption of the CDA-based standard in § 170.205(t)(2) expires on January 1, 2028.
                        </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 paragraph (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>
                        <P>
                            (6) 
                            <E T="03">Antimicrobial use and resistance reporting—transmission to public health agencies.</E>
                             Create antimicrobial use and resistance reporting information for electronic transmission in accordance 
                            <PRTPAGE P="63782"/>
                            with at least one of the versions of the standard specified in § 170.205(r).
                        </P>
                        <P>
                            (7) 
                            <E T="03">Health care surveys—transmission to public health agencies.</E>
                             Create health care survey information for electronic transmission in accordance with at least one of the versions of the standard specified in § 170.205(s).
                        </P>
                        <P>
                            (8) 
                            <E T="03">Birth reporting—Transmission to public health agencies</E>
                            —(i) 
                            <E T="03">Live birth.</E>
                             Create provider live birth report for electronic transmission in accordance with the standard specified in § 170.205(v).
                        </P>
                        <P>
                            (9) 
                            <E T="03">Prescription Drug Monitoring Program (PDMP) databases—query, receive, validate, parse, and filter: Functional requirement.</E>
                             Enable a user to query a PDMP, including bi-directional interstate exchange, to receive PDMP data in an interoperable manner, to establish access roles in accordance with applicable law, and to maintain records of access and auditable events as follows.
                        </P>
                        <P>
                            (i) 
                            <E T="03">Query.</E>
                             Enable both passive and active bi-directional query of a PDMP, including an interstate exchange query, in accordance with paragraphs (f)(9)(i)(A) through (C) of this section.
                        </P>
                        <P>(A) Initiate a passive or automated query of an applicable PDMP, including an interstate exchange query:</P>
                        <P>
                            (
                            <E T="03">1</E>
                            ) Upon the recording, change, or access of a medication order;
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) Upon the creation and transmission of an electronic prescription for a controlled substance; and
                        </P>
                        <P>
                            (
                            <E T="03">3</E>
                            ) Upon entry of controlled substance medication data into a medication list or reconciliation of a medication list including controlled substance medication data.
                        </P>
                        <P>(B) Enable an active or user-initiated query of a PDMP including an interstate exchange query.</P>
                        <P>(C) Send an acknowledgement message in response to receipt of data after a query is performed.</P>
                        <P>
                            (ii) 
                            <E T="03">Receive, validate, parse, and filter.</E>
                             Enable a user to receive, validate, parse, and filter electronic PDMP information in accordance with paragraphs (f)(9)(ii)(A) through (C) of this section.
                        </P>
                        <P>
                            (A) 
                            <E T="03">Receive.</E>
                             At a minimum, receive electronic controlled substance medication prescription information transmitted in accordance with (f)(9)(ii)(A)(
                            <E T="03">1</E>
                            ) through (
                            <E T="03">3</E>
                            ) of this section. As an alternative to enabling such receipt via paragraph (f)(9)(ii)(A)(
                            <E T="03">1</E>
                            ) through (
                            <E T="03">3</E>
                            ), receipt may also be optionally enabled through paragraph (f)(9)(ii)(A)(
                            <E T="03">4</E>
                            ) of this section:
                        </P>
                        <P>
                            (
                            <E T="03">1</E>
                            ) Receive through a method that conforms to the standard in § 170.202(d), from a service that has implemented the standard specified in § 170.202(a)(2);
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) Receive through a method that conforms to the standard in § 170.205(p)(1) when the technology is also using an SMTP-based edge protocol; and
                        </P>
                        <P>
                            (
                            <E T="03">3</E>
                            ) Receive via an application programming interface in accordance with the standard specified in § 170.215(a)(1).
                        </P>
                        <P>
                            (
                            <E T="03">4</E>
                            ) Optional: receive through a connection governed by the Trusted Exchange Framework and Common Agreement.
                        </P>
                        <P>
                            (B) 
                            <E T="03">Validate conformance—system performance.</E>
                             Demonstrate the ability to detect valid and invalid electronic controlled substance medication prescription information received. The Health IT Module must include the capability to:
                        </P>
                        <P>
                            (
                            <E T="03">1</E>
                            ) Identify valid electronic controlled substance medication prescription information received and process the data elements including any necessary data mapping to at least one of the versions of the USCDI standard in § 170.213 to enable use as discrete data elements, aggregation with other data, incorporation into a patient medication list, and parsing and filtering in accordance with paragraph (f)(9)(ii)(C);
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) Correctly interpret empty sections and null combinations;
                        </P>
                        <P>
                            (
                            <E T="03">3</E>
                            ) Detect errors in electronic controlled substance medication prescription information received including invalid vocabulary standards and data not represented using a vocabulary standard; and
                        </P>
                        <P>
                            (
                            <E T="03">4</E>
                            ) Record errors encountered and allow a user through at least one method to:
                        </P>
                        <P>
                            (
                            <E T="03">i</E>
                            ) Be notified of the errors produced;
                        </P>
                        <P>
                            (
                            <E T="03">ii</E>
                            ) Review the errors produced; and
                        </P>
                        <P>
                            (
                            <E T="03">iii</E>
                            ) Store or maintain error records for audit or other follow up action.
                        </P>
                        <P>
                            (C) 
                            <E T="03">Parse and filter.</E>
                             Enable a user to parse and filter electronic PDMP information received and validated in accordance with paragraph (f)(9)(ii)(B) at a minimum for any data element identified in at least one of the versions of the USCDI standard in § 170.213.
                        </P>
                        <P>
                            (iii) 
                            <E T="03">Access controls.</E>
                             Enable access controls including access roles and recording access including actions for auditable events and tamper-resistance in accordance with paragraphs (f)(9)(iii)(A) and (B) of this section.
                        </P>
                        <P>(A) Enable access roles for providers and pharmacists and enable a user to customize additional roles for any delegate or surrogate under applicable law.</P>
                        <P>(B) Record access actions and maintain an audit log of actions.</P>
                        <P>(10)-(20) [Reserved]</P>
                        <P>
                            (21) 
                            <E T="03">Immunization information—receive, validate, parse, filter, and exchange—response.</E>
                             Consistent with at least one of the versions of the standard and implementation specification specified in § 170.205(e), enable electronic immunization information to be received, validated, parsed, and filtered in accordance with paragraphs (f)(21)(i) through (iii) of this section and engage in exchange of immunization information in accordance with paragraph (f)(21)(iv) of this section.
                        </P>
                        <P>
                            (i) 
                            <E T="03">Receive.</E>
                             Receive electronic immunization information transmitted.
                        </P>
                        <P>
                            (A) 
                            <E T="03">Required.</E>
                             Through a method that conforms to Simple Object Access Protocol (SOAP)-based transport;
                        </P>
                        <P>
                            (B) 
                            <E T="03">Optional.</E>
                             (
                            <E T="03">1</E>
                            ) Receive through a connection governed by the Trusted Exchange Framework and Common Agreement;
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) Through a method that conforms to the standard specified in § 170.205(p)(1) when the technology is also using a Simple Mail Transfer Protocol (SMTP)-based edge protocol; or
                        </P>
                        <P>
                            (
                            <E T="03">3</E>
                            ) Via an application programming interface in accordance with the standard specified in § 170.215(a)(1) or at least one of the versions of the standard specified in § 170.215(d).
                        </P>
                        <P>
                            (ii) 
                            <E T="03">Validate conformance—system performance.</E>
                             Demonstrate the ability to detect valid and invalid electronic immunization information received and formatted in accordance with the standards specified in § 170.207(e)(5) and (6). The Health IT Module must include the capability to:
                        </P>
                        <P>(A) Identify valid electronic immunization information received and process the data elements required for the standards specified in § 170.207(e)(5) and (6). Processing must include any necessary data mapping to enable use as discrete data elements, aggregation with other data, and parsing and filtering in accordance with paragraph (f)(21)(iii) of this section;</P>
                        <P>(B) Correctly interpret empty sections and null combinations;</P>
                        <P>(C) Detect errors in immunization information received including invalid vocabulary standards and codes not specified in the standards specified in § 170.207(e)(5) and (6); and</P>
                        <P>(D) Record errors encountered and allow a user through at least one method to:</P>
                        <P>
                            (
                            <E T="03">1</E>
                            ) Be notified of the errors produced;
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) Review the errors produced; and,
                        </P>
                        <P>
                            (
                            <E T="03">3</E>
                            ) Store or maintain error records for audit or other follow up action.
                        </P>
                        <P>
                            (iii) 
                            <E T="03">Parse and filter.</E>
                             Enable a user to parse and filter immunization information received and validated in accordance with paragraph (f)(21)(ii) of 
                            <PRTPAGE P="63783"/>
                            this section according to the standard specified in § 170.207(e)(5) or (6).
                        </P>
                        <P>
                            (iv) 
                            <E T="03">Exchange—response.</E>
                             Functional requirement. Respond to incoming patient-level queries from external systems—this includes providing immunization information as structured data.
                        </P>
                        <P>
                            (22) 
                            <E T="03">Syndromic surveillance—receive, validate, parse, and filter.</E>
                             Consistent with at least one of the versions of the standard(s) and implementation specification(s) specified in § 170.205(d), enable a user to receive, validate, parse and filter electronic syndrome-based public health surveillance information in accordance with paragraphs (f)(22)(i) through (iii) of this section.
                        </P>
                        <P>
                            (i) 
                            <E T="03">Receive.</E>
                             Receive electronic syndrome-based public health surveillance information transmitted:
                        </P>
                        <P>
                            (A) 
                            <E T="03">Required.</E>
                             Through a method that conforms to a Secure File Transfer Protocol (SFTP) connection.
                        </P>
                        <P>
                            (B) 
                            <E T="03">Optional.</E>
                             Receipt also may be supported:
                        </P>
                        <P>
                            (
                            <E T="03">1</E>
                            ) Receive through a connection governed by the Trusted Exchange Framework and Common Agreement; or
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) Via an application programming interface in accordance with the standard specified in § 170.215(a)(1) or at least one of the versions of the standard specified in § 170.215(d).
                        </P>
                        <P>
                            (ii) 
                            <E T="03">Validate conformance—system performance.</E>
                             Demonstrate the ability to detect valid and invalid electronic syndrome-based public health surveillance information received. The Health IT Module must include the capability to:
                        </P>
                        <P>(A) Identify valid syndrome-based public health surveillance information received and process the data elements. Processing must include any necessary data mapping to enable use as discrete data elements, aggregation with other data, and parsing and filtering in accordance with paragraph (f)(22)(iii) of this section;</P>
                        <P>(B) Correctly interpret empty sections and null combinations;</P>
                        <P>(C) Detect errors in syndrome-based public health surveillance information received including invalid vocabulary standards and codes not specified; and</P>
                        <P>(D) Record errors encountered and allow a user through at least one method to:</P>
                        <P>
                            (
                            <E T="03">1</E>
                            ) Be notified of the errors produced;
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) Review the errors produced; and,
                        </P>
                        <P>
                            (
                            <E T="03">3</E>
                            ) Store or maintain error records for audit or other follow up action.
                        </P>
                        <P>
                            (iii) 
                            <E T="03">Parse and filter.</E>
                             Enable a user to parse and filter electronic syndrome-based public health surveillance information received and validated in accordance with paragraph (f)(22)(ii) of this section.
                        </P>
                        <P>
                            (23) 
                            <E T="03">Reportable laboratory test values/results—receive, validate, parse, and filter.</E>
                             Consistent with at least one of the standard(s) and implementation specification(s) specified in § 170.205(g)(1) or the Public Health Profile within the implementation specification in § 170.205(g)(3), enable a user to receive, validate, parse and filter electronic reportable laboratory test values/results in accordance with paragraphs (f)(23)(i) through (iii) of this section.
                        </P>
                        <P>
                            (i) 
                            <E T="03">Receive.</E>
                             Receive electronic reportable laboratory test values/results transmitted:
                        </P>
                        <P>
                            (A) 
                            <E T="03">Required.</E>
                             (
                            <E T="03">1</E>
                            ) Through a method that conforms to the standard specified in § 170.202(d), from a service that has implemented the standard specified in § 170.202(a)(2); and
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) Through a method that conforms to the standard in § 170.205(p)(1) when the technology is also using an SMTP-based edge protocol.
                        </P>
                        <P>
                            (B) 
                            <E T="03">Optional.</E>
                             (
                            <E T="03">1</E>
                            ) Receive through a connection governed by the Trusted Exchange Framework and Common Agreement
                            <SU>SM</SU>
                            ; or
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) Via an application programming interface in accordance with the standard specified in § 170.215(a)(1) or at least one of the versions of the standard specified in § 170.215(d).
                        </P>
                        <P>
                            (ii) 
                            <E T="03">Validate conformance—system performance.</E>
                             Demonstrate the ability to detect valid and invalid electronic reportable laboratory test values/results received. The Health IT Module must include the capability to:
                        </P>
                        <P>(A) Identify valid electronic reportable laboratory test values/results received and process the data elements. Processing must include any necessary data mapping to enable use as discrete data elements, aggregation with other data, and parsing and filtering in accordance with paragraph (f)(23)(iii) of this section;</P>
                        <P>(B) Correctly interpret empty sections and null combinations;</P>
                        <P>(C) Detect errors in electronic reportable laboratory test values/results received including invalid vocabulary standards and codes not specified; and</P>
                        <P>(D) Record errors encountered and allow a user through at least one method to:</P>
                        <P>
                            (
                            <E T="03">1</E>
                            ) Be notified of the errors produced;
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) Review the errors produced; and,
                        </P>
                        <P>
                            (
                            <E T="03">3</E>
                            ) Store or maintain error records for audit or other follow up action.
                        </P>
                        <P>
                            (iii) 
                            <E T="03">Parse and filter.</E>
                             Enable a user to parse and filter electronic reportable laboratory test values/results received and validated in accordance with paragraph (f)(23)(ii) of this section.
                        </P>
                        <P>
                            (24) 
                            <E T="03">Cancer pathology reporting—receive, validate, parse, and filter.</E>
                             Consistent with the standard(s) and implementation specification(s) specified in § 170.205(i)(4), enable a user to receive, validate, parse and filter cancer pathology reports in accordance with paragraphs (f)(24)(i) through (iii) of this section.
                        </P>
                        <P>
                            (i) 
                            <E T="03">Receive.</E>
                             Receive electronic cancer pathology reports transmitted:
                        </P>
                        <P>
                            (A) 
                            <E T="03">Required.</E>
                             Via an application programming interface in accordance with the standard specified in § 170.215(a)(1) or at least one of the versions of the standard specified in § 170.215(d).
                        </P>
                        <P>
                            (B) 
                            <E T="03">Optional.</E>
                             Receive through a connection governed by the Trusted Exchange Framework and Common Agreement.
                        </P>
                        <P>
                            (ii) 
                            <E T="03">Validate conformance—system performance.</E>
                             Demonstrate the ability to detect valid and invalid electronic cancer pathology reports received. The Health IT Module must include the capability to:
                        </P>
                        <P>(A) Identify valid electronic cancer pathology reports received and process the data elements. Processing must include any necessary data mapping to enable use as discrete data elements, aggregation with other data, and parsing and filtering in accordance with paragraph (f)(24)(iii) of this section;</P>
                        <P>(B) Correctly interpret empty sections and null combinations;</P>
                        <P>(C) Detect errors in electronic cancer pathology reports received including invalid vocabulary standards and codes not specified; and</P>
                        <P>(D) Record errors encountered and allow a user through at least one method to:</P>
                        <P>
                            (
                            <E T="03">1</E>
                            ) Be notified of the errors produced;
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) Review the errors produced; and,
                        </P>
                        <P>
                            (
                            <E T="03">3</E>
                            ) Store or maintain error records for audit or other follow up action.
                        </P>
                        <P>
                            (iii) 
                            <E T="03">Parse and filter.</E>
                             Enable a user to parse and filter electronic reportable cancer pathology reports received and validated in accordance with paragraph (f)(24)(ii) of this section.
                        </P>
                        <P>
                            (25) 
                            <E T="03">Electronic case reporting—receive, validate, parse, filter electronic initial case reports and reportability response; and create and transmit reportability response.</E>
                             Consistent with at least one of the standard(s) and implementation specification(s) specified in § 170.205(t), enable a user to receive, validate, parse, and filter electronic case reporting information in accordance with paragraphs (f)(25)(i) through (iii) of this section, and to create and transmit a reportability response in accordance with paragraph (f)(25)(iv) of this section.
                        </P>
                        <P>
                            (i) 
                            <E T="03">Receive.</E>
                             Receive electronic case reporting information transmitted:
                            <PRTPAGE P="63784"/>
                        </P>
                        <P>
                            (A) 
                            <E T="03">Required.</E>
                             Via an application programming interface in accordance with the standard specified in § 170.215(a)(1) or at least one of the versions of the standard specified in § 170.215(d).
                        </P>
                        <P>
                            (B) 
                            <E T="03">Optional.</E>
                             (
                            <E T="03">1</E>
                            ) Receive through a connection governed by the Trusted Exchange Framework and Common Agreement;
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) Through a method that conforms to the standard specified in § 170.205(p)(1) when the technology is also using an SMTP-based edge protocol.
                        </P>
                        <P>
                            (ii) 
                            <E T="03">Validate conformance—system performance.</E>
                             Demonstrate the ability to detect valid and invalid electronic case reporting information received. The Health IT Module must include the capability to:
                        </P>
                        <P>(A) Identify valid electronic case reporting information received and process the data elements for, at a minimum, the data classes expressed in at least one of the versions of the USCDI standard specified in § 170.213. Processing must include any necessary data mapping to enable use as discrete data elements, aggregation with other data, and parsing and filtering in accordance with paragraph (f)(25)(iii) of this section;</P>
                        <P>(B) Correctly interpret empty sections and null combinations;</P>
                        <P>(C) Detect errors in electronic case reporting information received including invalid vocabulary standards and codes not specified; and</P>
                        <P>(D) Record errors encountered and allow a user through at least one method to:</P>
                        <P>
                            (
                            <E T="03">1</E>
                            ) Be notified of the errors produced;
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) Review the errors produced; and,
                        </P>
                        <P>
                            (
                            <E T="03">3</E>
                            ) Store or maintain error records for audit or other follow up action.
                        </P>
                        <P>
                            (iii) 
                            <E T="03">Parse and filter.</E>
                             Enable a user to parse and filer electronic case reporting information received and validated in accordance with paragraph (f)(25)(ii) of this section, at a minimum, for any data element identified in at least one of the versions of the USCDI standard specified in § 170.213.
                        </P>
                        <P>
                            (iv) 
                            <E T="03">Reportability response.</E>
                             Enable a user to create a response in accordance with the HL7 eCR FHIR IG in § 170.205(t)(3) and transmit the response.
                        </P>
                        <P>(26)-(27) [Reserved]</P>
                        <P>
                            (28) 
                            <E T="03">Birth reporting—receive, validate, parse, and filter.</E>
                             Consistent with the standard(s) and implementation specification(s) specified in § 170.205(v), enable a user to receive, validate, parse, and filter birth reporting information in accordance with paragraphs (f)(28)(i) through (iii) of this section.
                        </P>
                        <P>
                            (i) 
                            <E T="03">Receive.</E>
                             Receive electronic birth reports transmitted:
                        </P>
                        <P>
                            (A) 
                            <E T="03">Required.</E>
                             Via an application programming interface in accordance with the standard specified in § 170.215(a)(1) or at least one of the versions of the standard specified in § 170.215(d).
                        </P>
                        <P>
                            (B) 
                            <E T="03">Optional.</E>
                             (
                            <E T="03">1</E>
                            ) Receive through a connection governed by the Trusted Exchange Framework and Common Agreement;
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) Through a method that conforms to the standard specified in § 170.202(d), from a service that has implemented the standard specified in § 170.202(a)(2); or
                        </P>
                        <P>
                            (
                            <E T="03">3</E>
                            ) Through a method that conforms to the standard in § 170.205(p) when the technology is also using an SMTP-based edge protocol.
                        </P>
                        <P>
                            (ii) 
                            <E T="03">Validate conformance—system performance.</E>
                             Demonstrate the ability to detect valid and invalid electronic birth reports received. The Health IT Module must include the capability to:
                        </P>
                        <P>(A) Identify valid electronic birth report received and process the data elements. Processing must include any necessary data mapping to enable use as discrete data elements, aggregation with other data, and parsing and filtering in accordance with paragraph (f)(28)(iii) of this section;</P>
                        <P>(B) Correctly interpret empty sections and null combinations;</P>
                        <P>(C) Detect errors in electronic birth reports received including invalid vocabulary standards and codes not specified; and,</P>
                        <P>(D) Record errors encountered and allow a user through at least one method to:</P>
                        <P>
                            (
                            <E T="03">1</E>
                            ) Be notified of the errors produced;
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) Review the errors produced; and,
                        </P>
                        <P>
                            (
                            <E T="03">3</E>
                            ) Store or maintain error records for audit or other follow up action.
                        </P>
                        <P>
                            (iii) 
                            <E T="03">Parse and filter.</E>
                             Enable a user to parse and filter electronic birth reports received and validated in accordance with paragraph (f)(28)(ii) of this section.
                        </P>
                        <P>
                            (29) 
                            <E T="03">Prescription Drug Monitoring Program (PDMP) data—receive, validate, parse, filter prescription data, support query and exchange.</E>
                             Enable a user to receive and validate electronic prescription information for controlled substance medications in accordance with paragraphs (f)(29)(i) through (ii), and support query of PDMP and exchange of PDMP data in accordance with paragraphs (f)(29)(iii) and (iv) of this section.
                        </P>
                        <P>
                            (i) 
                            <E T="03">Receive.</E>
                             Receive electronic prescription information for controlled substances transmitted:
                        </P>
                        <P>
                            (A) 
                            <E T="03">Required.</E>
                             (
                            <E T="03">1</E>
                            ) Through a method that conforms to the standard in § 170.202(d), from a service that has implemented the standard specified in § 170.202(a)(2);
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) Through a method that conforms to the standard in § 170.205(p)(1) when the technology is also using an SMTP-based edge protocol; and
                        </P>
                        <P>
                            (
                            <E T="03">3</E>
                            ) Via an application programming interface in accordance with the standard specified in § 170.215(a)(1) or at least one of the versions of the standard specified in § 170.215(d).
                        </P>
                        <P>
                            (B) 
                            <E T="03">Optional.</E>
                             Receive through a connection governed by the Trusted Exchange Framework and Common Agreement.
                        </P>
                        <P>
                            (ii) 
                            <E T="03">Validate conformance—system performance.</E>
                             Demonstrate the ability to detect valid and invalid electronic controlled substance medication prescription information received. The Health IT Module must include the capability to:
                        </P>
                        <P>(A) Identify valid electronic controlled substance medication prescription information received and process the data elements including any necessary data mapping or translation between standards;</P>
                        <P>(B) Correctly interpret empty sections and null combinations;</P>
                        <P>(C) Detect errors in electronic controlled substance medication prescription information received including invalid vocabulary standards and data not represented using a vocabulary standard; and,</P>
                        <P>(D) Record errors encountered and allow a user through at least on method to:</P>
                        <P>
                            (
                            <E T="03">1</E>
                            ) Be notified of the errors produced;
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) Review the errors produced; and,
                        </P>
                        <P>
                            (
                            <E T="03">3</E>
                            ) Store or maintain error records for audit or other follow up action.
                        </P>
                        <P>
                            (iii) 
                            <E T="03">Parse and filter.</E>
                             Enable a user to parse and filter electronic controlled substance medication prescription information received and validated in accordance with paragraph (f)(29)(ii) of this section.
                        </P>
                        <P>
                            (iv) 
                            <E T="03">Query and exchange.</E>
                             Enable patient-level queries from external systems of electronic controlled substance medication prescription information of the PDMP including an interstate exchange query in accordance with:
                        </P>
                        <P>
                            (A) 
                            <E T="03">Exchange—response.</E>
                             Respond to incoming patient-level queries from external system.
                        </P>
                        <P>
                            (B) 
                            <E T="03">Exchange—patient access.</E>
                             Enable patient access to view electronic controlled substance medication prescription information.
                        </P>
                        <P>
                            (g) 
                            <E T="03">Design and performance</E>
                            —(1) 
                            <E T="03">Automated numerator recording.</E>
                             For each Promoting Interoperability Programs percentage-based measure, technology must be able to create a report or file that enables a user to 
                            <PRTPAGE P="63785"/>
                            review the patients or actions that would make the patient or action eligible to be included in the measure's numerator. The information in the report or file created must be of sufficient detail such that it enables a user to match those patients or actions to meet the measure's denominator limitations when necessary to generate an accurate percentage.
                        </P>
                        <P>
                            (2) 
                            <E T="03">Automated measure calculation.</E>
                             For each Promoting Interoperability Programs percentage-based measure that is supported by a capability included in a technology, record the numerator and denominator and create a report including the numerator, denominator, and resulting percentage associated with each applicable measure.
                        </P>
                        <P>
                            (3) 
                            <E T="03">Safety-enhanced design.</E>
                             (i) 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 certification criterion's expiration date), and (14) and (b)(2), (3), and (11) of this section.
                        </P>
                        <P>
                            (ii) 
                            <E T="03">Number of test participants.</E>
                             A minimum of 10 test participants must be used for the testing of each capability identified in paragraph (g)(3)(i) of this section.
                        </P>
                        <P>(iii) One of the following must be submitted on the user-centered design processed used:</P>
                        <P>(A) Name, description, and citation (URL and/or publication citation) for an industry or Federal Government standard.</P>
                        <P>(B) Name the process(es), provide an outline of the process(es), a short description of the process(es), and an explanation of the reason(s) why use of any of the existing user-centered design standards was impractical.</P>
                        <P>(iv) The following information/sections from NISTIR 7742 must be submitted for each capability to which user-centered design processes were applied:</P>
                        <P>(A) Name and product version; date and location of the test; test environment; description of the intended users; and total number of participants;</P>
                        <P>(B) Description of participants, including: Sex; age; education; occupation/role; professional experience; computer experience; and product experience;</P>
                        <P>(C) Description of the user tasks that were tested and association of each task to corresponding certification criteria;</P>
                        <P>(D) The specific metrics captured during the testing of each user task performed in (g)(3)(iv)(C) of this section, which must include: Task success (%); task failures (%); task standard deviations (%); task performance time; and user satisfaction rating (based on a scale with 1 as very difficult and 5 as very easy) or an alternative acceptable user satisfaction measure;</P>
                        <P>(E) Test results for each task using the metrics identified above in paragraph (g)(3)(iv)(D) of this section; and</P>
                        <P>(F) Results and data analysis narrative, including: Major test finding; effectiveness; efficiency; satisfaction; and areas for improvement.</P>
                        <P>(v) Submit test scenarios used in summative usability testing.</P>
                        <P>
                            (4) 
                            <E T="03">Quality management system.</E>
                             (i) For each capability that a technology includes and for which that capability's certification is sought, the use of a Quality Management System (QMS) in the development, testing, implementation, and maintenance of that capability must be identified that satisfies one of the following ways:
                        </P>
                        <P>(A) The QMS used is established by the Federal government or a standards developing organization.</P>
                        <P>(B) The QMS used is mapped to one or more QMS established by the Federal government or standards developing organization(s).</P>
                        <P>(ii) When a single QMS was used for applicable capabilities, it would only need to be identified once.</P>
                        <P>(iii) When different QMS were applied to specific capabilities, each QMS applied would need to be identified.</P>
                        <P>
                            (5) 
                            <E T="03">Accessibility-centered design.</E>
                             For each capability that a Health IT Module includes and for which that capability's certification is sought, the use of a health IT accessibility-centered design standard or law in the development, testing, implementation and maintenance of that capability must be identified.
                        </P>
                        <P>(i) When a single accessibility-centered design standard or law was used for applicable capabilities, it would only need to be identified once.</P>
                        <P>(ii) When different accessibility-centered design standards and laws were applied to specific capabilities, each accessibility-centered design standard or law applied would need to be identified. This would include the application of an accessibility-centered design standard or law to some capabilities and none to others.</P>
                        <P>(iii) When no accessibility-centered design standard or law was applied to all applicable capabilities such a response is acceptable to satisfy this certification criterion.</P>
                        <P>
                            (6) 
                            <E T="03">Consolidated CDA creation performance.</E>
                             The following technical and performance outcomes must be demonstrated related to Consolidated CDA creation. The capabilities required under paragraphs (g)(6)(i) through (v) of this section can be demonstrated in tandem and do not need to be individually addressed in isolation or sequentially.
                        </P>
                        <P>(i) This certification criterion's scope includes:</P>
                        <P>
                            (A) The data classes expressed in the standards in § 170.213 in accordance with § 170.205(a)(4) and (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>
                        <P>(C) The following data classes:</P>
                        <P>
                            (
                            <E T="03">1</E>
                            ) 
                            <E T="03">Assessment and plan of treatment.</E>
                             In accordance with the “Assessment and Plan Section (V2)” of the standard specified in § 170.205(a)(4); or in accordance with the “Assessment Section (V2)” and “Plan of Treatment Section (V2)” of the standard specified in § 170.205(a)(4).
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) 
                            <E T="03">Goals.</E>
                             In accordance with the “Goals Section” of the standard specified in § 170.205(a)(4).
                        </P>
                        <P>
                            (
                            <E T="03">3</E>
                            ) 
                            <E T="03">Health concerns.</E>
                             In accordance with the “Health Concerns Section” of the standard specified in § 170.205(a)(4).
                        </P>
                        <P>
                            (
                            <E T="03">4</E>
                            ) 
                            <E T="03">Unique device identifier(s) for a patient's implantable device(s).</E>
                             In accordance with the “Product Instance” in the “Procedure Activity Procedure Section” of the standard specified in § 170.205(a)(4).
                        </P>
                        <P>
                            (ii) 
                            <E T="03">Reference C-CDA match.</E>
                             (A) For health IT certified to (g)(6)(i)(A) of this section, create a data file formatted in accordance with the standard adopted in § 170.205(a)(4) and (5) that matches a gold-standard, reference data file.
                        </P>
                        <P>(B) For health IT certified to (g)(6)(i)(B) of this section, create a data file formatted in accordance with the standard adopted in § 170.205(a)(4) that matches a gold-standard, reference data file.</P>
                        <P>
                            (iii) 
                            <E T="03">Document-template conformance.</E>
                             (A) For health IT certified to (g)(6)(i)(A) of this section, create a data file formatted in accordance with the standard adopted in § 170.205(a)(4) and (5) that demonstrates a valid implementation of each document template applicable to the certification criterion or criteria within the scope of the certificate sought.
                        </P>
                        <P>
                            (B) For health IT certified to (g)(6)(i)(B) of this section, create a data file formatted in accordance with the standard adopted in § 170.205(a)(4) that demonstrates a valid implementation of each document template applicable to the certification criterion or criteria 
                            <PRTPAGE P="63786"/>
                            within the scope of the certificate sought.
                        </P>
                        <P>
                            (iv) 
                            <E T="03">Vocabulary conformance.</E>
                             (A) For health IT certified to paragraph (g)(6)(i)(A) of this section, create a data file formatted in accordance with the standard adopted in § 170.205(a)(4) and (5) that demonstrates the required vocabulary standards (and value sets) are properly implemented.
                        </P>
                        <P>(B) For health IT certified to paragraph (g)(6)(i)(B) of this section, create a data file formatted in accordance with the standard adopted in § 170.205(a)(4) that demonstrates the required vocabulary standards (and value sets) are properly implemented.</P>
                        <P>
                            (v) 
                            <E T="03">Completeness verification.</E>
                             Create a data file for each of the applicable document templates referenced in paragraph (g)(6)(iii) of this section without the omission of any of the data included in either paragraph (g)(6)(i)(A) or (B) of this section, as applicable.
                        </P>
                        <P>
                            (7) 
                            <E T="03">Application access—patient selection.</E>
                             The following technical outcome and conditions must be met through the demonstration of an application programming interface (API).
                        </P>
                        <P>
                            (i) 
                            <E T="03">Functional requirement.</E>
                             The technology must be able to receive a request with sufficient information to uniquely identify a patient and return an ID or other token that can be used by an application to subsequently execute requests for that patient's data.
                        </P>
                        <P>(ii) [Reserved]</P>
                        <P>(8) [Reserved]</P>
                        <P>
                            (9) 
                            <E T="03">Application access—all data request.</E>
                             The following technical outcome and conditions must be met through the demonstration of an application programming interface.
                        </P>
                        <P>
                            (i) 
                            <E T="03">Functional requirements.</E>
                             (A)(
                            <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 at least one of the versions of the USCDI standard 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)(3)(
                            <E T="03">i</E>
                            ) through (
                            <E T="03">v</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 at least one of the versions of the USCDI standard 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)(3)(
                            <E T="03">i</E>
                            ) through (
                            <E T="03">v</E>
                            ) of this section.
                        </P>
                        <P>
                            (
                            <E T="03">3</E>
                            ) The following data classes:
                        </P>
                        <P>
                            (
                            <E T="03">i</E>
                            ) 
                            <E T="03">Assessment and plan of treatment.</E>
                             In accordance with the “Assessment and Plan Section (V2)” of the standards specified in § 170.205(a)(4); or in accordance with the “Assessment Section (V2)” and “Plan of Treatment Section (V2)” of the standards specified in § 170.205(a)(4).
                        </P>
                        <P>
                            (
                            <E T="03">ii</E>
                            ) 
                            <E T="03">Goals.</E>
                             In accordance with the “Goals Section” of the standards specified in § 170.205(a)(4).
                        </P>
                        <P>
                            (
                            <E T="03">iii</E>
                            ) 
                            <E T="03">Health concerns.</E>
                             In accordance with the “Health Concerns Section” of the standards specified in § 170.205(a)(4).
                        </P>
                        <P>
                            (
                            <E T="03">iv</E>
                            ) 
                            <E T="03">Unique device identifier(s) for a patient's implantable device(s).</E>
                             In accordance with the “Product Instance” in the “Procedure Activity Procedure Section” of the standards specified in § 170.205(a)(4).
                        </P>
                        <P>
                            (
                            <E T="03">v</E>
                            ) 
                            <E T="03">Imaging link.</E>
                             On and after January 1, 2028, an imaging link.
                        </P>
                        <P>(B) Respond to requests for patient data associated with a specific date as well as requests for patient data within a specified date range.</P>
                        <P>(ii) [Reserved]</P>
                        <P>
                            (10) 
                            <E T="03">Standardized API for patient and population services.</E>
                             Support the following capabilities to enable API-based access to EHI for patients, users, and systems:
                        </P>
                        <P>
                            (i) 
                            <E T="03">Registration.</E>
                             For the period up to and including December 31, 2027, enable apps to register with the Health IT Module's “authorization server” by meeting either the requirements specified in paragraph (g)(10)(i)(A) or both paragraphs (g)(10)(i)(A) and (B) of this section. On and after January 1, 2028, enable apps to register with the Health IT Module's “authorization server” by meeting the requirements specified in paragraphs (g)(10)(i)(A) and (B) of this section.
                        </P>
                        <P>
                            (A) 
                            <E T="03">Functional registration.</E>
                             Support functional registration for confidential and public apps according to the requirements in § 170.315(j)(1).
                        </P>
                        <P>
                            (B) 
                            <E T="03">Dynamic registration.</E>
                             Support dynamic registration for confidential apps according to the requirements in § 170.315(j)(2).
                        </P>
                        <P>
                            (ii) 
                            <E T="03">Patient and user access</E>
                            —(A) 
                            <E T="03">Authentication and authorization for patient and user access</E>
                            —(
                            <E T="03">1</E>
                            ) 
                            <E T="03">Authentication and authorization for patient access</E>
                            —(
                            <E T="03">i</E>
                            ) 
                            <E T="03">SMART authentication and authorization for patient access.</E>
                             Support authentication and authorization during the process of granting access to patient data to patients according to the requirements in paragraph (j)(9) of this section.
                        </P>
                        <P>
                            (
                            <E T="03">ii</E>
                            ) 
                            <E T="03">Asymmetric certificate-based authentication for patient access.</E>
                             For the period up to and including December 31, 2027, may support asymmetric certificate-based authentication according to the requirements in paragraph(j)(5) of this section for patient-facing apps dynamically registered using the capabilities in paragraph (g)(10)(i)(B) of this section. On and after January 1, 2028, must support asymmetric certificate-based authentication according to the requirements in paragraph (j)(5) of this section for patient-facing apps dynamically registered using the capabilities in paragraph (g)(10)(i)(B).
                        </P>
                        <P>
                            (
                            <E T="03">iii</E>
                            ) 
                            <E T="03">Multi-factor authentication.</E>
                             For the period up to and including December 31, 2027, may meet the requirements specified in paragraph (d)(13)(ii) of this section for patient-facing authentication. On and after January 1, 2028, must meet the requirements specified in paragraph (d)(13)(ii) for patient-facing authentication.
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) 
                            <E T="03">Authentication and authorization for user access</E>
                            —(
                            <E T="03">i</E>
                            ) 
                            <E T="03">SMART authentication and authorization for user access.</E>
                             For the period up to and including December 31, 2027, support authentication and authorization during the process of granting access to patient data to users according to the requirements in paragraph (j)(10)(i) of this section and may also support user authorization revocation according to paragraph (j)(10)(ii) of this section. On and after January 1, 2028, must also support user authorization revocation according to paragraph (j)(10)(ii).
                        </P>
                        <P>
                            (
                            <E T="03">ii</E>
                            ) 
                            <E T="03">Asymmetric certificate-based authentication for B2B user access.</E>
                             For the period up to and including December 31, 2027, may also support asymmetric certificate-based authentication according to the requirements in paragraph (j)(11) of this section for user-facing apps dynamically registered using the capabilities in paragraph (g)(10)(i)(B) of this section. On and after January 1, 2028, must support asymmetric certificate-based authentication according to the requirements in paragraph (j)(11) for user-facing apps dynamically registered using the capabilities in paragraph (g)(10)(i)(B).
                        </P>
                        <P>
                            (B) 
                            <E T="03">Information access.</E>
                             Support the following methods to allow access to patient data for patient-facing apps and user-facing apps:
                        </P>
                        <P>
                            (
                            <E T="03">1</E>
                            ) 
                            <E T="03">Read and search API.</E>
                             Support read and search capabilities in one of the standards adopted in § 170.215(a) and support the “US Core Server CapabilityStatement” of the 
                            <PRTPAGE P="63787"/>
                            corresponding implementation specification adopted in § 170.215(b)(1) for each of the data elements included in at least one of the versions of the USCDI standard adopted in § 170.213. Support for imaging links requests is optional. On and after January 1, 2028, requests for imaging links must be supported.
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) 
                            <E T="03">Verifiable health records.</E>
                             For the period up to and including December 31, 2027, may also support the issuance of verifiable health records for vaccination status and infectious disease-related laboratory testing according to the requirements specified in paragraph (j)(22) of this section. On and after January 1, 2028, must support the issuance of verifiable health records for vaccination status and infectious disease-related laboratory testing according to the requirements specified in paragraph (j)(22).
                        </P>
                        <P>
                            (
                            <E T="03">3</E>
                            ) 
                            <E T="03">Subscriptions.</E>
                             For the period up to and including December 31, 2027, may also support subscriptions as a server for patient-facing apps and user-facing apps according to the requirements specified in paragraph (j)(23) of this section. On and after January 1, 2028, must support subscriptions as a server for patient-facing apps and user-facing apps according to the requirements specified in paragraph (j)(23).
                        </P>
                        <P>
                            (iii) 
                            <E T="03">System access</E>
                            —(A) 
                            <E T="03">Authentication and authorization for system access</E>
                            —(
                            <E T="03">1</E>
                            ) 
                            <E T="03">SMART Backend Services system authentication and authorization.</E>
                             Support system authentication and authorization according to the requirements in paragraph (j)(7) of this section for system apps functionally registered using the capabilities in paragraph (g)(10)(i)(A) of this section.
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) 
                            <E T="03">Asymmetric certificate-based system authentication and authorization.</E>
                             For the period up to and including December 31, 2027, may also support asymmetric certificate-based system authentication and authorization according to the requirements in paragraph (j)(8) of this section for system apps dynamically registered using the capabilities in paragraph (g)(10)(i)(B) of this section. On and after January 1, 2028, must support asymmetric certificate-based system authentication and authorization according to the requirements in paragraph (j)(8) for system apps dynamically registered using the capabilities in paragraph (g)(10)(i)(B).
                        </P>
                        <P>
                            (B) 
                            <E T="03">Information access.</E>
                             Support the following methods to allow access to patient data for system apps:
                        </P>
                        <P>
                            (
                            <E T="03">1</E>
                            ) 
                            <E T="03">Read and search API.</E>
                             Support read and search capabilities in one of the standards adopted in § 170.215(a) and support the “US Core Server CapabilityStatement” of the corresponding implementation specification adopted in § 170.215(b)(1) for each of the data included in at least one of the versions of the USCDI standard adopted in § 170.213. Support for imaging links requests is optional. On and after January 1, 2028, requests for imaging links must be supported.
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) 
                            <E T="03">Bulk FHIR API.</E>
                             For the time period up to and including December 31, 2027, a Health IT Module must support read capabilities in at least one of the standards adopted in § 170.215(a), at least one of the implementation specifications adopted in § 170.215(b)(1), and at least one of the versions of the implementation specification adopted in § 170.215(d) for each of the data classes and data elements included in at least one of the versions of the USCDI standard adopted in § 170.213. Support for imaging links requests is optional. On and after January 1, 2028, requests for imaging links must be supported. Additionally, for the time period up to and including December 31, 2027, a Health IT Module must meet either the requirements specified in paragraph (g)(10)(iii)(B)(
                            <E T="03">2</E>
                            )(
                            <E T="03">i</E>
                            ) or both paragraphs (g)(10)(iii)(B)(
                            <E T="03">2</E>
                            )(
                            <E T="03">i</E>
                            ) and (
                            <E T="03">ii</E>
                            ) of this section according to at least one of the versions of the implementation specification adopted in § 170.215(d). On and after January 1, 2028, a Health IT Module must meet the requirements specified in paragraphs (g)(10)(iii)(B)(
                            <E T="03">2</E>
                            )(
                            <E T="03">i</E>
                            ) and (
                            <E T="03">ii</E>
                            ) of this section according to at least one of the versions of the implementation specification adopted in § 170.215(d).
                        </P>
                        <P>
                            (
                            <E T="03">i</E>
                            ) The “GroupLevelExport” operation; and
                        </P>
                        <P>
                            (
                            <E T="03">ii</E>
                            ) The “type” query parameter for each of the data classes and data elements included in at least one of the versions of the USCDI standard adopted in § 170.213 and imaging links.
                        </P>
                        <P>
                            (
                            <E T="03">3</E>
                            ) 
                            <E T="03">Subscriptions.</E>
                             For the time period up to and including December 31, 2027, may support subscriptions as a server for system apps according to the requirements specified in paragraph (j)(23) of this section. On and after January 1, 2028, must support subscriptions as a server for system apps according to the requirements specified in paragraph (j)(23).
                        </P>
                        <P>
                            (iv) 
                            <E T="03">Workflow triggers for decision support interventions.</E>
                             For the time period up to and including December 31, 2027, may support workflow triggers for decision support interventions according to the requirements specified in paragraphs (j)(20) and (g)(10)(iv)(A) of this section. On and after January 1, 2028, support workflow triggers for decision support interventions by supporting the capabilities specified in paragraph (j)(20), including the following:
                        </P>
                        <P>
                            (A) 
                            <E T="03">Workflow triggers.</E>
                             Support the execution of decision support workflow triggers in accordance with the implementation specification in § 170.215(f)(1), including support for “patient-view” and “order-sign” hooks.
                        </P>
                        <P>(B) [Reserved]</P>
                        <P>(11)-(19) [Reserved]</P>
                        <P>
                            (20) 
                            <E T="03">Standardized API for public health data exchange.</E>
                             Support the following capabilities to enable API-based access, exchange, and use of EHI for public health purposes.
                        </P>
                        <P>
                            (i) 
                            <E T="03">Registration.</E>
                             Support the following registration capabilities to support the full scope of API capabilities in paragraph (g)(20) of this section:
                        </P>
                        <P>
                            (A) 
                            <E T="03">Functional registration.</E>
                             Support functional registration for confidential apps according to the requirements in paragraph (j)(1) of this section.
                        </P>
                        <P>
                            (B) 
                            <E T="03">Dynamic registration.</E>
                             Support dynamic registration for confidential apps according to the requirements in paragraph (j)(2) of this section.
                        </P>
                        <P>
                            (ii) 
                            <E T="03">Authentication and authorization for system access</E>
                            —(A) 
                            <E T="03">SMART Backend Services system authentication and authorization.</E>
                             Support system authentication and authorization according to the requirements in paragraph (j)(7) of this section for system apps functionally registered using the capabilities in paragraph (g)(20)(i)(A) of this section.
                        </P>
                        <P>
                            (B) 
                            <E T="03">Asymmetric certificate-based system authentication and authorization.</E>
                             Support asymmetric certificate-based system authentication and authorization according to the requirements in paragraph (j)(8) of this section for system apps dynamically registered using the capabilities in paragraph (g)(20)(i)(B) of this section.
                        </P>
                        <P>
                            (iii) 
                            <E T="03">Public health information access—</E>
                            (A) 
                            <E T="03">Public Health Profiles.</E>
                             Support the HL7 FHIR Profiles specified in the implementation specification in § 170.215(b)(2) for the following HL7 FHIR Resources:
                        </P>
                        <P>
                            (
                            <E T="03">1</E>
                            ) Condition;
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) Encounter;
                        </P>
                        <P>
                            (
                            <E T="03">3</E>
                            ) Location;
                        </P>
                        <P>
                            (
                            <E T="03">4</E>
                            ) Observation;
                        </P>
                        <P>
                            (
                            <E T="03">5</E>
                            ) Organization;
                        </P>
                        <P>
                            (
                            <E T="03">6</E>
                            ) Patient;
                        </P>
                        <P>
                            (
                            <E T="03">7</E>
                            ) Practitioner role.
                        </P>
                        <P>
                            (B) 
                            <E T="03">Information access.</E>
                             Support the following methods to allow access to patient data:
                        </P>
                        <P>
                            <E T="03">(1) Read and search API—</E>
                            (
                            <E T="03">i</E>
                            ) 
                            <E T="03">Read.</E>
                             Support the ability for a system client to read HL7 FHIR Resources using the “id” data element for the HL7 FHIR Resources included in paragraph (g)(20)(iii)(A) of this section, and return 
                            <PRTPAGE P="63788"/>
                            the information profiled according to the implementation specification in § 170.215(b)(2).
                        </P>
                        <P>
                            (
                            <E T="03">ii</E>
                            ) 
                            <E T="03">Search.</E>
                             Support the ability for a system client to search HL7 FHIR Resources according to the applicable search requirements in the “US Core Server Capability Statement” for the HL7 FHIR Resources included in paragraph (g)(20)(iii)(A) of this section and return the information profiled according to the implementation specification in § 170.215(b)(2).
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) 
                            <E T="03">Bulk FHIR API.</E>
                             Support read and search capabilities in one of the standards and implementation specifications adopted in § 170.215(a) and at least one of the versions of the standard specified in § 170.215(d) for the HL7 FHIR Resources included in paragraph (g)(20)(iii)(A) of this section, and return the information profiled according to the implementation specification in § 170.215(b)(2). Additionally, for the time period up to and including December 31, 2027, a Health IT Module must meet either the requirements specified in paragraph (g)(20)(iii)(B)(
                            <E T="03">2</E>
                            )(
                            <E T="03">i</E>
                            ) of this section or both paragraphs (g)(20)(iii)(B)(
                            <E T="03">2</E>
                            )(
                            <E T="03">i</E>
                            ) and (
                            <E T="03">ii</E>
                            ) of this section according to at least one of the versions of the implementation specification adopted in § 170.215(d). On and after January 1, 2028, a Health IT Module must meet the requirements specified in paragraphs (g)(20)(iii)(B)(
                            <E T="03">2</E>
                            )(
                            <E T="03">i</E>
                            ) and (
                            <E T="03">ii</E>
                            ) of this section according to at least one of the versions of the implementation specification adopted in § 170.215(d).
                        </P>
                        <P>
                            (
                            <E T="03">i</E>
                            ) The “GroupLevelExport” operation; and
                        </P>
                        <P>
                            (
                            <E T="03">ii</E>
                            ) The “_type” query parameter for each of the data included in paragraph (g)(20)(iii)(A) of this section.
                        </P>
                        <P>
                            (C) 
                            <E T="03">Subscriptions.</E>
                             Support subscriptions according to the requirements in paragraph (j)(23) of this section, including:
                        </P>
                        <P>
                            (
                            <E T="03">1</E>
                            ) Support the ability for a client to subscribe to notifications filtered according to the conditions below and send notifications for the following event-based interactions according to the standard in § 170.215(a) and implementation specification in § 170.215(h)(1):
                        </P>
                        <P>
                            (
                            <E T="03">i</E>
                            ) When a patient encounter starts, filtered by “Encounter.reasonCode” and “Encounter.subject”;
                        </P>
                        <P>
                            (
                            <E T="03">ii</E>
                            ) When a patient encounter ends, filtered by “Encounter.reasonCode” and “Encounter.subject”.
                        </P>
                        <P>(21)-(29) [Reserved]</P>
                        <P>
                            (30) 
                            <E T="03">Patient access API.</E>
                             Support the following capabilities to enable patients to access health and administrative information.
                        </P>
                        <P>
                            (i) 
                            <E T="03">Registration.</E>
                             Support the following registration capabilities to support the full scope of API capabilities in paragraph (g)(30) of this section:
                        </P>
                        <P>
                            (A) 
                            <E T="03">Functional registration.</E>
                             Support functional registration for confidential and public apps according to the requirements included in paragraph (j)(1) of this section.
                        </P>
                        <P>
                            (B) 
                            <E T="03">Dynamic registration.</E>
                             Support dynamic registration for confidential apps according to the requirements in paragraph (j)(2) of this section.
                        </P>
                        <P>
                            (ii) 
                            <E T="03">Authentication and authorization for patient access</E>
                            —(A) 
                            <E T="03">SMART authentication and authorization for patient access.</E>
                             Support authentication and authorization during the process of granting access to patient data to patients according to the requirements in paragraph (j)(9) of this section.
                        </P>
                        <P>
                            (B) 
                            <E T="03">Asymmetric certificate-based authentication for patient access.</E>
                             Support asymmetric certificate-based authentication according to the requirements in paragraph (j)(5) of this section for patient-facing apps dynamically registered using the capabilities in paragraph (g)(30)(i)(B) of this section.
                        </P>
                        <P>
                            (C) 
                            <E T="03">Multi-factor authentication.</E>
                             On and after January 1, 2028, meet the requirements specified in paragraph (d)(13)(ii) of this section for patient facing authentication.
                        </P>
                        <P>
                            (iii) 
                            <E T="03">Drug formulary API.</E>
                             Publish information regarding the payer's drug formulary via a standardized API(s) according to at least one of the versions of the implementation specification adopted in § 170.215(m), including the requirements described in the “US Drug Formulary Server Capability Statement.”
                        </P>
                        <P>
                            (A) 
                            <E T="03">Authenticated API.</E>
                             Provide support for the “Authenticated API” according to at least one of the versions of the implementation specification adopted in § 170.215(m) and requirements in paragraphs (g)(30)(i) and (ii) of this section.
                        </P>
                        <P>
                            (B) 
                            <E T="03">Unauthenticated API.</E>
                             Provide support for the “Unauthenticated API” according to at least one of the versions of the implementation specification adopted in § 170.215(m).
                        </P>
                        <P>
                            (iv) 
                            <E T="03">Patient health information, coverage, and claims API</E>
                            —(A) 
                            <E T="03">Patient access to clinical and coverage information.</E>
                             Allow patients to access and share clinical and coverage information via a standardized API(s) according to at least one of the versions of the implementation specification adopted in § 170.215(k)(2).
                        </P>
                        <P>
                            (
                            <E T="03">1</E>
                            ) Support the ability for patients to authenticate and share information with an application, service, or health plan according to at least one of the versions of the implementation specification adopted in § 170.215(k)(2), including support for:
                        </P>
                        <P>
                            (
                            <E T="03">i</E>
                            ) The requirements associated with the “Oauth2.0 or SMART-on-FHIR Member-authorized Exchange” exchange method, including the requirements in the section “OAuth2.0 and FHIR API.”
                        </P>
                        <P>
                            (
                            <E T="03">ii</E>
                            ) The requirements included in the “PDEX Server Capability Statement” and the HL7 FHIR Profiles, Resources, and operations included in Section 4.5.4 “Capability Statement” according to at least one of the versions of the implementation specification adopted in § 170.215(k)(2).
                        </P>
                        <P>
                            (
                            <E T="03">iii</E>
                            ) The capabilities described in “US Core Server Capability Statement” according to at least one of the versions of the implementation specification adopted in § 170.215(b)(1) for each of the data classes and data elements included in at least one of the versions of the USCDI standard adopted in § 170.213.
                        </P>
                        <P>
                            (B) 
                            <E T="03">Patient access to claims information.</E>
                             Allow patients to access claims information via a standardized API(s) according to at least one of the versions of the implementation specification adopted in § 170.215(k)(1).
                        </P>
                        <P>
                            (
                            <E T="03">1</E>
                            ) Support the “Authentication and Authorization Requirements” section of at least one of the versions of the implementation specification adopted in § 170.215(k)(1).
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) Support the requirements described in the “C4BB CapabilityStatement” according to at least one of the versions of the implementation specifications adopted in § 170.215(k)(1).
                        </P>
                        <P>
                            (31) 
                            <E T="03">Provider access API</E>
                            —
                            <E T="03">client.</E>
                             Support the following capabilities to enable a provider to request and receive patient clinical and coverage information from a payer and receive and process the response.
                        </P>
                        <P>(i) Support the ability to request patient history from a payer according to at least one of the versions of the implementation specification adopted in § 170.215(k)(2).</P>
                        <P>
                            (ii) 
                            <E T="03">API interactions.</E>
                             Support the following API interactions as a client.
                        </P>
                        <P>
                            (A) 
                            <E T="03">Read and search API</E>
                            —(
                            <E T="03">1</E>
                            ) 
                            <E T="03">Clinical and coverage information.</E>
                             Support the ability to interact with a “PDEX Server” as a client, including support for all the corresponding client capabilities for requirements in the “PDEX Server CapabilityStatement” and the HL7 FHIR Profiles, Resources, and operations included in Section 4.5.4 “CapabilityStatement” according to at least one of the versions of the implementation specification adopted in § 170.215(k)(2).
                            <PRTPAGE P="63789"/>
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) 
                            <E T="03">Claims information.</E>
                             Support all the corresponding client capabilities for requirements included in the “C4BB CapabilityStatement” according to at least one of the versions of the implementation specification adopted in § 170.215(k)(1).
                        </P>
                        <P>
                            (
                            <E T="03">3</E>
                            ) 
                            <E T="03">USCDI and US Core.</E>
                             The corresponding client capabilities described in “US Core Server CapabilityStatement” according to at least one of the versions of the implementation specification adopted in § 170.215(b)(1) for each of the data classes and data elements included in at least one of the versions of the USCDI standard adopted in § 170.213.
                        </P>
                        <P>
                            (B) 
                            <E T="03">Bulk FHIR API.</E>
                             Support the ability to request and receive information as a client according to at least one of the versions of the standard adopted in § 170.215(a) and at least one of the versions of the implementation specification adopted in § 170.215(d) for each of the data included in paragraph (g)(31)(ii)(A) of this section. Additionally, for the time period up to and including December 31, 2027, a Health IT Module must meet either the requirements specified in paragraph (g)(31)(ii)(B)(
                            <E T="03">1</E>
                            ) of this section or both paragraphs (g)(31)(ii)(B)(
                            <E T="03">1</E>
                            ) and (
                            <E T="03">2</E>
                            ) of this section according to at least one of the versions of the implementation specification adopted in § 170.215(d). On and after January 1, 2028, a Health IT Module must meet the requirements specified in paragraphs (g)(31)(ii)(B)(
                            <E T="03">1</E>
                            ) and (
                            <E T="03">2</E>
                            ) of this section according to at least one of the versions of the implementation specification adopted in § 170.215(d).
                        </P>
                        <P>
                            (
                            <E T="03">1</E>
                            ) The “GroupLevelExport” operation; and
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) The “_type” query parameter for each of the data included in paragraph (g)(31)(ii)(A) of this section.
                        </P>
                        <P>
                            (iii) 
                            <E T="03">Information receipt.</E>
                             Support the ability to receive, parse, and write patient health history, coverage, and claims information to the Health IT Module for:
                        </P>
                        <P>
                            (A) 
                            <E T="03">Clinical and coverage information.</E>
                             All HL7 FHIR Profiles and Resources included in the “PDEX Server CapabilityStatement” and the HL7 FHIR Profiles and Resources included in the Section 4.5.4 “CapabilityStatement” according to at least one of the versions of the implementation specification adopted in § 170.215(k)(2).
                        </P>
                        <P>
                            (B) 
                            <E T="03">Claims information.</E>
                             Claims information by supporting the information included in the “C4BB CapabilityStatement” according to at least one of the versions of the implementation specification adopted in § 170.215(k)(1).
                        </P>
                        <P>
                            (C) 
                            <E T="03">USCDI and US Core.</E>
                             The capabilities described in the “US Core Server CapabilityStatement” according to at least one of the versions of the implementation specification adopted in § 170.215(b)(1) for each of the data classes and data elements included in at least one of the versions of the USCDI standard adopted in § 170.213.
                        </P>
                        <P>
                            (32) 
                            <E T="03">Provider access API—server.</E>
                             Support the following capabilities to enable providers to request and receive patient health history and coverage information from payers.
                        </P>
                        <P>
                            (i) 
                            <E T="03">Registration.</E>
                             Support the following registration capabilities to support the full scope of API capabilities in paragraph (g)(32) of this section:
                        </P>
                        <P>(A) Support functional registration for confidential apps according to the requirements included in paragraph (j)(1) of this section.</P>
                        <P>(B) Support dynamic registration for confidential apps according to the requirements in paragraph (j)(2) of this section.</P>
                        <P>
                            (ii) 
                            <E T="03">Authentication and authorization</E>
                            —(A) 
                            <E T="03">Authentication and authorization for user access.</E>
                             Support the ability to authenticate and authorize an app during the process of granting access to patient data to users according to at least one of the versions of the implementation specification adopted in § 170.215(k)(2) and at least one implementation specification adopted in § 170.215(c).
                        </P>
                        <P>
                            (
                            <E T="03">1</E>
                            ) 
                            <E T="03">Asymmetric certificate-based authentication for B2B user access.</E>
                             Support asymmetric certificate-based authentication according to the requirements in paragraph (j)(11) of this section for user-facing apps dynamically registered using the capabilities in paragraph (g)(32)(i)(B) of this section.
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) [Reserved]
                        </P>
                        <P>
                            (B) 
                            <E T="03">Authentication and authorization for system access.</E>
                             Support the ability to authenticate and authorize an app during the process of granting access to patient data to system apps according to at least one of the versions of the standard adopted in § 170.215(a) and at least one of the versions of the implementation specification adopted in § 170.215(d).
                        </P>
                        <P>
                            (
                            <E T="03">1</E>
                            ) 
                            <E T="03">SMART Backend Services system authentication and authorization.</E>
                             Support system authentication and authorization according to the requirements in paragraph (j)(7) of this section for system apps functionally registered using the capabilities in paragraph (g)(32)(i)(A) of this section.
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) 
                            <E T="03">Asymmetric certificate-based system authentication and authorization.</E>
                             Support asymmetric certificate-based system authentication and authorization according to the requirements in paragraph (j)(8) of this section for system apps dynamically registered using the capabilities in paragraph (g)(32)(i)(B) of this section.
                        </P>
                        <P>
                            (iii) 
                            <E T="03">Information access.</E>
                             Support the following capabilities to allow a provider to request patient health and coverage information from a payer and to receive a response.
                        </P>
                        <P>
                            (A) 
                            <E T="03">Request.</E>
                             Support the ability for a client to request patient health history, coverage, and claims information according to at least one of the versions of the implementation specification adopted in § 170.215(k)(2).
                        </P>
                        <P>
                            (B) 
                            <E T="03">Lookup.</E>
                             Support the ability to identify patient clinical, coverage, and claims information based on the information provided by the client in paragraph (g)(32)(iii)(A) of this section.
                        </P>
                        <P>
                            (C) 
                            <E T="03">Supported information and capabilities</E>
                            —(
                            <E T="03">1</E>
                            ) 
                            <E T="03">Clinical and coverage information.</E>
                             Support the requirements described in the “PDEX Server CapabilityStatement” and the HL7 FHIR Profiles and operations included in Section 4.5.4 “CapabilityStatement” via a standardized API according to at least one of the versions of the implementation specification adopted in § 170.215(k)(2).
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) 
                            <E T="03">Claims information.</E>
                             Support the requirements in the in the “C4BB CapabilityStatement” according to at least one of the versions of the implementation specification adopted in § 170.215(k)(1).
                        </P>
                        <P>
                            (
                            <E T="03">3</E>
                            ) 
                            <E T="03">USCDI and US Core.</E>
                             The capabilities described in “US Core Server CapabilityStatement” according to at least one of the versions of the implementation specification adopted in § 170.215(b)(1) for each of the data classes and data elements included in at least one of the versions of the USCDI standard adopted in § 170.213.
                        </P>
                        <P>
                            (D) 
                            <E T="03">Response.</E>
                             Support returning patient clinical, coverage, and non-financial claims and encounter information according to at least one of the versions of the implementation specification adopted in § 170.215(k)(2) for each of the data included in paragraphs (g)(32)(C)(
                            <E T="03">1</E>
                            ) through (
                            <E T="03">3</E>
                            ) of this section.
                        </P>
                        <P>
                            (E) 
                            <E T="03">Bulk FHIR API.</E>
                             A Health IT Module must support responding to requests for patient data according to at least one of the versions of the standard adopted in § 170.215(a) and at least one of the versions of the implementation specification adopted in § 170.215(d) for each of the data included in paragraphs (g)(32)(C)(
                            <E T="03">1</E>
                            ) through (
                            <E T="03">3</E>
                            ) of this section. Additionally, for the time period up to and including December 31, 2027, a Health IT Module must meet either the requirements specified in paragraph (g)(32)(iii)(E)(
                            <E T="03">1</E>
                            ) of this section or both 
                            <PRTPAGE P="63790"/>
                            paragraphs (g)(32)(iii)(E)(
                            <E T="03">1</E>
                            ) and (
                            <E T="03">2</E>
                            ) of this section according to at least one of the versions of the implementation specification adopted in § 170.215(d). On and after January 1, 2028, a Health IT Module must meet the requirements specified in paragraphs (g)(32)(iii)(E)(
                            <E T="03">1</E>
                            ) and (
                            <E T="03">2</E>
                            ) of this section according to at least one of the versions of the implementation specification adopted in § 170.215(d).
                        </P>
                        <P>
                            (
                            <E T="03">1</E>
                            ) The “GroupLevelExport” operation; and
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) The “_type” query parameter for each of the data included in paragraphs (g)(32)(C) through (E) of this section.
                        </P>
                        <P>
                            (33) 
                            <E T="03">Payer-to-payer API.</E>
                             Support the following capabilities to enable payers to exchange patient health information with other payers via a standardized API(s).
                        </P>
                        <P>
                            (i) 
                            <E T="03">Registration.</E>
                             Support the following registration capabilities to support the full scope of API capabilities in paragraph (g)(33) of this section:
                        </P>
                        <P>
                            (A) 
                            <E T="03">Functional registration.</E>
                             Support registration for confidential apps according to the requirements included in paragraph (j)(1) of this section.
                        </P>
                        <P>
                            (B) 
                            <E T="03">Dynamic registration.</E>
                             Support dynamic registration for confidential apps according to the requirements included in paragraph (j)(2) of this section.
                        </P>
                        <P>
                            (ii) 
                            <E T="03">Authentication and authorization</E>
                            —(A) 
                            <E T="03">SMART Backend Services system authentication and authorization.</E>
                             Support system authentication and authorization according to the requirements in paragraph (j)(7) of this section for system apps functionally registered using the capabilities in paragraph (g)(33)(i)(A) of this section.
                        </P>
                        <P>
                            (B) 
                            <E T="03">Asymmetric certificate-based system authentication and authorization.</E>
                             Support asymmetric certificate-based system authentication and authorization according to the requirements in paragraph (j)(8) of this section for system apps dynamically registered using the capabilities in paragraph (g)(33)(i)(B) of this section.
                        </P>
                        <P>
                            (iii) 
                            <E T="03">Information access.</E>
                             (A) Support the requirements included in the “Payer-to-Payer Exchange” section of at least one of the versions of the implementation specifications adopted in § 170.215(k)(2) as a client and server including support for the following to allow access to information in paragraphs (g)(33)(iii)(B) through (D) of this section:
                        </P>
                        <P>
                            (
                            <E T="03">1</E>
                            ) Support the following “Data Retrieval Methods” from at least one of the implementation specifications adopted in § 170.215(k)(2): “Query all clinical resource individually,” “$patient-everything operation,” and “Bulk FHIR Asynchronous protocols.”
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) 
                            <E T="03">Bulk FHIR API.</E>
                             For the time period up to and including December 31, 2027, a Health IT Module must respond to requests for patient data according to at least one of the versions of the standard adopted in § 170.215(a), and at least one of the versions of the implementation specification adopted in § 170.215(d) for each of the data elements included in paragraphs (g)(33)(iii)(B) through (D) of this section. Additionally, for the time period up to and including December 31, 2027, a Health IT Module must meet either the requirements specified in paragraph (g)(33)(iii)(A)(2)(
                            <E T="03">i</E>
                            ) or both paragraphs (g)(33)(iii)(A)(
                            <E T="03">2</E>
                            )(
                            <E T="03">i</E>
                            ) and (
                            <E T="03">ii</E>
                            ) of this section according to at least one of the versions of the implementation specification adopted in § 170.215(d). On and after January 1, 2028, a Health IT Module must meet the requirements specified in paragraphs (g)(33)(iii)(A)(2)(
                            <E T="03">i</E>
                            ) and (
                            <E T="03">ii</E>
                            ) of this section according to at least one of the versions of the implementation specification adopted in § 170.215(d).
                        </P>
                        <P>
                            (
                            <E T="03">i</E>
                            ) The “GroupLevelExport” operation; and
                        </P>
                        <P>
                            (
                            <E T="03">ii</E>
                            ) The “_type” query parameter for each of the data classes and data elements included in at least one of the versions of the USCDI standard adopted in § 170.213.
                        </P>
                        <P>
                            (B) 
                            <E T="03">Clinical and coverage information.</E>
                             Support the requirements described in the “PDEX Server CapabilityStatement” as a client and server via a standardized API according to at least one of the versions of the implementation specification adopted in § 170.215(k)(2).
                        </P>
                        <P>
                            (C) 
                            <E T="03">Claims information.</E>
                             Support claims information by supporting the data included in the “C4BB CapabilityStatement” according to at least one of the versions of the implementation specification adopted in § 170.215(k)(1).
                        </P>
                        <P>
                            (D) 
                            <E T="03">USCDI and US Core.</E>
                             The capabilities described in “US Core Server CapabilityStatement” according to at least one of the versions of the implementation specification adopted in § 170.215(b)(1) for each of the data classes and data elements included in at least one of the versions of the USCDI standard adopted in § 170.213.
                        </P>
                        <P>
                            (34) 
                            <E T="03">Prior authorization API</E>
                            —
                            <E T="03">provider.</E>
                             Support the following capabilities to enable providers to request and receive coverage requirements from payers at the time treatment decisions are being made.
                        </P>
                        <P>
                            (i) 
                            <E T="03">Coverage discovery.</E>
                             Support the following capabilities to initiate and exchange information with payer systems as a client to support the identification of coverage requirements.
                        </P>
                        <P>(A) Support the “Privacy, Security, and Safety” section of at least one of the versions of the implementation specification adopted in § 170.215(j)(1).</P>
                        <P>(B) Support the capabilities in paragraph (j)(20) of this section to enable workflow triggers to call decision support services, including the following:</P>
                        <P>
                            (
                            <E T="03">1</E>
                            ) Support “appointment-book”, “encounter-start”, “encounter-discharge”, “order-dispatch”, “order-select,” and “order-sign” CDS Hooks according to at least one of the versions of the implementation specification adopted in § 170.215(j)(1) and requirements in paragraph (j)(20) of this section.
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) [Reserved]
                        </P>
                        <P>(C) Support the requirements applicable to “CRD Clients” in at least one of the versions of the implementation specification adopted in § 170.215(j)(1) including:</P>
                        <P>
                            (
                            <E T="03">1</E>
                            ) The requirements in the “CRD Client CapabilityStatement.”
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) The “SHOULD” requirements applicable to “CRD Clients” in Section 5.8 “Additional Data Retrieval.”
                        </P>
                        <P>
                            (ii) 
                            <E T="03">Documentation and rules exchange.</E>
                             Support the ability to request and populate prior authorization documentation templates and rules from payer systems according to at least one of the versions of the implementation specification adopted in § 170.215(j)(2).
                        </P>
                        <P>
                            (A) 
                            <E T="03">Light DTR capabilities.</E>
                             (
                            <E T="03">1</E>
                            ) Support the capabilities included in the “Light DTR EHR” CapabilityStatement according to at least one of the versions of the implementation specification adopted in § 170.215(j)(2).
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) 
                            <E T="03">Registration.</E>
                             Support the following capabilities to support the full scope of API capabilities in paragraph (g)(34)(ii)(A) of this section:
                        </P>
                        <P>
                            (
                            <E T="03">i</E>
                            ) 
                            <E T="03">Functional registration.</E>
                             Support functional registration of the “DTR SMART Client” according to the requirements included in paragraph (j)(1) of this section.
                        </P>
                        <P>
                            (
                            <E T="03">ii</E>
                            ) 
                            <E T="03">Dynamic registration.</E>
                             Support dynamic registration of the “DTR SMART Client” according to the requirements included in paragraph (j)(2) of this section.
                        </P>
                        <P>
                            (
                            <E T="03">3</E>
                            ) 
                            <E T="03">App Launch, authentication, and authorization.</E>
                             Support launching the “DTR SMART Client” according to at least one of the versions of the implementation specification adopted in § 170.215(j)(2) to allow providers to launch an app to complete documentation for prior authorization according to at least one of the versions of the implementation specifications adopted in § 170.215(j)(2).
                        </P>
                        <P>
                            (
                            <E T="03">i</E>
                            ) 
                            <E T="03">SMART authentication and authorization for user access.</E>
                             Support 
                            <PRTPAGE P="63791"/>
                            authentication and authorization during the process of granting access to patient data to users according to the requirements in paragraph (j)(10) of this section.
                        </P>
                        <P>
                            (
                            <E T="03">ii</E>
                            ) 
                            <E T="03">Asymmetric certificate-based authentication for B2B user access.</E>
                             Support asymmetric certificate-based authentication according to the requirements in paragraph (j)(11) of this section for the “Light DTR Client” dynamically registered using the capabilities in paragraph (g)(34)(ii)(A)(
                            <E T="03">2</E>
                            )(
                            <E T="03">ii</E>
                            ) of this section.
                        </P>
                        <P>
                            (B) 
                            <E T="03">Full DTR capabilities.</E>
                             Support the capabilities included in the “Full DTR EHR” CapabilityStatement according to at least one of the versions of the implementation specification adopted in § 170.215(j)(2).
                        </P>
                        <P>
                            (iii) 
                            <E T="03">Prior authorization submission.</E>
                             Support the following capabilities to submit a prior authorization request to a payer system.
                        </P>
                        <P>
                            (
                            <E T="03">A</E>
                            ) 
                            <E T="03">Prior authorization transactions.</E>
                             Support the ability to submit a prior authorization request to a payer system according to at least one of the implementation specifications adopted in 170.215(j)(3), including the following requirements:
                        </P>
                        <P>
                            (
                            <E T="03">1</E>
                            ) Support the “EHR PAS Capabilities” CapabilityStatement according to at least one of the versions of the implementation specification adopted in § 170.215(j)(3).
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) Support the ability to include documentation created in paragraph (g)(34)(ii) of this section in a prior authorization request to a payer system according to at least one of the versions of the implementation specifications adopted in § 170.215(j)(3).
                        </P>
                        <P>
                            (
                            <E T="03">3</E>
                            ) Support the ability to consume and process a “ClaimResponse” according to at least one of the versions of the implementation specification adopted in § 170.215(j)(3).
                        </P>
                        <P>
                            (
                            <E T="03">4</E>
                            ) Support subscriptions as a client according to the requirements in paragraph (j)(24) of this section and at least one of the versions of the implementation specification adopted in § 170.215(j)(3) in order to support “pended authorization responses”.
                        </P>
                        <P>(B) [Reserved]</P>
                        <P>
                            (35) 
                            <E T="03">Prior authorization API</E>
                            —
                            <E T="03">payer.</E>
                             Support the following capabilities to enable providers to request and receive coverage requirements from payers at the time treatment decisions are being made.
                        </P>
                        <P>
                            (i) 
                            <E T="03">Coverage discovery.</E>
                             Support the following capabilities to exchange information with provider systems to support the identification of coverage requirements.
                        </P>
                        <P>(A) Support the ability to receive and respond to decision support requests as a service by supporting the capabilities in paragraph (j)(21) of this section.</P>
                        <P>(B) Support the requirements applicable to “CRD Server” included in at least one of the versions of the implementation specification adopted in paragraph (j)(1) of this section including the requirements in the “CRD Server CapabilityStatement.”</P>
                        <P>
                            (ii) 
                            <E T="03">Documentation and rules exchange.</E>
                             Support the following capabilities to exchange prior authorization documentation requirements with provider systems.
                        </P>
                        <P>
                            (A) 
                            <E T="03">Registration.</E>
                             Support the following registration capabilities to support the full scope of API capabilities in this paragraph (g)(35)(ii):
                        </P>
                        <P>
                            (
                            <E T="03">1</E>
                            ) 
                            <E T="03">Functional registration.</E>
                             Support functional registration for the “DTR SMART Client” and “Full DTR EHR” according to the requirements included in paragraph (j)(1) of this section.
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) 
                            <E T="03">Dynamic registration.</E>
                             Support dynamic registration for the “DTR SMART Client” and “Full DTR EHR” according to the requirements included in paragraph (j)(2) of this section.
                        </P>
                        <P>
                            (B) 
                            <E T="03">Authentication and authorization for system access</E>
                            —(
                            <E T="03">1</E>
                            ) 
                            <E T="03">SMART Backend Services system authentication and authorization.</E>
                             Support system authentication and authorization according to the requirements in paragraph (j)(7) of this section for the “DTR SMART Client” and “Full DTR EHR” functionally registered using the capabilities in paragraph (g)(35)(ii)(A)(
                            <E T="03">1</E>
                            ) of this section.
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) 
                            <E T="03">Asymmetric certificate-based system authentication and authorization.</E>
                             Support asymmetric certificate-based system authentication and authorization according to the requirements in paragraph (j)(8) of this section for the “DTR SMART Client” and “Full DTR EHR” dynamically registered using the capabilities in paragraph (g)(35)(ii)(A)(
                            <E T="03">2</E>
                            ) of this section.
                        </P>
                        <P>
                            (C) 
                            <E T="03">Prior authorization documentation exchange.</E>
                             Support the ability to receive and respond to a prior authorization documentation request with documentation templates and rules according to at least one of the versions of the implementation specification adopted in § 170.215(j)(2), including:
                        </P>
                        <P>
                            (
                            <E T="03">1</E>
                            ) Support the capabilities included in the “DTR Payer Service” CapabilityStatement according to at least one of the versions of the implementation specification adopted in § 170.215(j)(2).
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) [Reserved]
                        </P>
                        <P>
                            (iii) 
                            <E T="03">Prior authorization receipt and response.</E>
                             Support the following capabilities to receive and respond to a prior authorization request.
                        </P>
                        <P>
                            (A) 
                            <E T="03">Registration.</E>
                             Support the following registration capabilities to support the full scope of API capabilities in this paragraph (g)(35)(iii):
                        </P>
                        <P>
                            (
                            <E T="03">1</E>
                            ) 
                            <E T="03">Functional registration.</E>
                             Support functional registration for confidential apps according to the requirements included in paragraph (j)(1) of this section.
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) 
                            <E T="03">Dynamic registration.</E>
                             Support dynamic registration according to the requirements included in paragraph (j)(2) of this section.
                        </P>
                        <P>
                            (B) 
                            <E T="03">Authentication and authorization for system access</E>
                            —(
                            <E T="03">1</E>
                            ) 
                            <E T="03">SMART Backend Services system authentication and authorization.</E>
                             Support system authentication and authorization according to the requirements in paragraph (j)(7) of this section for system apps functionally registered using the capabilities in paragraph (g)(35)(iii)(A)(
                            <E T="03">1</E>
                            ) of this section.
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) 
                            <E T="03">Asymmetric certificate-based system authentication and authorization.</E>
                             Support asymmetric certificate-based system authentication and authorization according to the requirements in paragraph (j)(8) of this section for system apps dynamically registered using the capabilities in paragraph (g)(35)(iii)(A)(
                            <E T="03">2</E>
                            ) of this section.
                        </P>
                        <P>
                            (C) 
                            <E T="03">Prior authorization transactions.</E>
                             Support the ability to receive, process, and respond to a prior authorization request according to at least one of the versions of the implementation specification adopted in § 170.215(j)(3), including the following requirements:
                        </P>
                        <P>
                            (
                            <E T="03">1</E>
                            ) Support the “Intermediary PAS Capabilities” according to at least one of the versions of the implementation specification adopted in § 170.215(j)(3).
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) Support an endpoint for receiving prior authorization requests according to at least one of the versions of the implementation specification adopted in § 170.215(j)(3).
                        </P>
                        <P>
                            (
                            <E T="03">3</E>
                            ) Support the ability to respond to a prior authorization request with a “ClaimResponse” according to at least one of the versions of the implementation specification adopted in § 170.215(j)(3).
                        </P>
                        <P>
                            (
                            <E T="03">4</E>
                            ) Support subscriptions as a server according to the requirements of at least one of the versions of the implementation specification in § 170.215(j)(3) including support for “pended authorization responses.”
                        </P>
                        <P>
                            (36) 
                            <E T="03">Provider directory API—health plan coverage.</E>
                             Support the ability to publish a payer's insurance plans, their associated networks, and the organizations and providers that participate in these networks according to at least one of the versions of the implementation specification adopted 
                            <PRTPAGE P="63792"/>
                            in § 170.215(n), including the requirements described in the “Plan-Net CapabilityStatement.”
                        </P>
                        <P>
                            (h) 
                            <E T="03">Transport methods and other protocols</E>
                            —(1) 
                            <E T="03">Direct project</E>
                            —(i) 
                            <E T="03">Applicability Statement for Secure Health Transport.</E>
                             Able to send and receive health information in accordance with the standard specified in § 170.202(a)(2), including formatted only as a “wrapped” message.
                        </P>
                        <P>
                            (ii) 
                            <E T="03">Delivery notification in direct.</E>
                             Able to send and receive health information in accordance with the standard specified in § 170.202(e)(1).
                        </P>
                        <P>
                            (2) 
                            <E T="03">Direct project, edge protocol, and XDR/XDM.</E>
                             (i) Able to send and receive health information in accordance with:
                        </P>
                        <P>(A) The standard specified in § 170.202(a)(2), including formatted only as a “wrapped” message;</P>
                        <P>(B) The standard specified in § 170.202(b), including support for both limited and full XDS metadata profiles; and</P>
                        <P>(C) Both edge protocol methods specified by the standard in § 170.202(d).</P>
                        <P>
                            (ii) 
                            <E T="03">Delivery notification in direct.</E>
                             Able to send and receive health information in accordance with the standard specified in § 170.202(e)(1).
                        </P>
                        <P>
                            (j) 
                            <E T="03">Modular API capabilities.</E>
                             The following technical outcomes and conditions must be met through the demonstration of application programming interface technology.
                        </P>
                        <P>
                            (1) 
                            <E T="03">Functional registration.</E>
                             Support the ability to register applications with a Health IT Module's authorization server.
                        </P>
                        <P>
                            (2) 
                            <E T="03">Dynamic registration.</E>
                             Support the ability to dynamically register confidential apps according to the implementation specifications adopted in § 170.215(o), including mandatory support for sections “Home,” “Discovery,” and “Registration” as well as the “community” query parameter as defined in section “Multiple Trust Communities” of the implementation specifications adopted in § 170.215(o).
                        </P>
                        <P>(3)-(4) [Reserved]</P>
                        <P>
                            (5) 
                            <E T="03">Asymmetric certificate-based authentication for patient access.</E>
                             Support asymmetric certificate-based authentication during the process of granting access to patient data to patients according to the implementation specifications adopted in § 170.215(o), including support for asymmetric certificate-based authentication as detailed in section “Consumer-Facing” of the implementation specifications adopted in § 170.215(o).
                        </P>
                        <P>
                            (6) 
                            <E T="03">SMART App Launch user authorization.</E>
                             Support user authorization during the process of granting access to patient data according to at least one of the implementation specifications adopted in § 170.215(c), including support for:
                        </P>
                        <P>
                            (i) 
                            <E T="03">Refresh tokens.</E>
                             Support issuing a refresh token valid for a period of no less than three months to confidential apps and native apps capable of securing a refresh token.
                        </P>
                        <P>
                            (ii) 
                            <E T="03">Token introspection.</E>
                             Support the ability to receive and validate tokens issued by the Health IT Module in accordance with at least one implementation specification adopted in § 170.215(c).
                        </P>
                        <P>
                            (iii) 
                            <E T="03">Persistent access until revocation.</E>
                             Support the ability for a user to enable for confidential apps persistent access to patient information without requiring user re-authentication or re-authorization until authorization revocation at the user's direction.
                        </P>
                        <P>
                            (iv) 
                            <E T="03">User 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 user's direction within 1 hour of the request.
                        </P>
                        <P>
                            (7) 
                            <E T="03">SMART Backend Services system authentication and authorization.</E>
                             Support system authentication and authorization during the process of granting access to patient data in accordance with the “Backend Services” section of at least one implementation specification adopted in § 170.215(c), including support for:
                        </P>
                        <P>
                            (i) 
                            <E T="03">Token introspection.</E>
                             Support the ability to receive and validate tokens issued by the Health IT Module in accordance with at least one implementation specification adopted in § 170.215(c).
                        </P>
                        <P>(ii) [Reserved]</P>
                        <P>
                            (8) 
                            <E T="03">Asymmetric certificate-based system authentication and authorization.</E>
                             Support system authentication and authorization for the “client_credentials” grant type during the process of granting access to patient data according to the implementation specifications adopted in § 170.215(o), including support for the “Business-to-Business” section of the implementation specifications adopted in § 170.215(o) and the following:
                        </P>
                        <P>
                            (i) 
                            <E T="03">Token introspection.</E>
                             Support the ability to receive and validate tokens issued by the Health IT Module in accordance with at least one implementation specification in § 170.215(c).
                        </P>
                        <P>(ii) [Reserved]</P>
                        <P>
                            (9) 
                            <E T="03">SMART patient access for standalone apps.</E>
                             Support patient authorization and authorization revocation at a patient's direction according to the requirements in § 170.315(j)(6), including support for one of the following sets of SMART capabilities listed in paragraphs (j)(9)(i) through (iii) of this section. For the time period up to and including December 31, 2025, a Health IT Module must meet either the requirements specified in paragraph (j)(9)(i), (ii), or (iii) of this section. For the time period up to and including December 31, 2027, a Health IT Module must meet either the requirements specified in paragraph (j)(9)(ii) or (iii) of this section. On and after January 1, 2028, a Health IT Module must meet the requirements specified in paragraph (j)(9)(iii) of this section.
                        </P>
                        <P>(i) Support the “Patient Access for Standalone Apps” Capability Set, as well as the capabilities of “launch-standalone” and “context-standalone-patient,” and the capabilities in subsections “Client Types,” “Single Sign-on,” and “Permissions” except the “permission-user” capability according to the implementation specification adopted in § 170.215(c)(1).</P>
                        <P>(ii) Support the “Patient Access for Standalone Apps” Capability Set as well as the capabilities of “launch-standalone” and “context-standalone-patient,” and the capabilities in subsections “Authorization Methods,” “Client Types,” “Single Sign-on,” and “Permissions” except the “permission-online” and “permission-user” capabilities according to the implementation specification adopted in § 170.215(c)(2).</P>
                        <P>(iii) Support the “Patient Access for Standalone Apps” Capability Set as well as the capabilities of “launch-standalone” and “context-standalone-patient,” and the capabilities in subsections “Authorization Methods,” “Client Types,” “Single Sign-on,” and “Permissions” except the “permission-online” and “permission-user” capabilities according to the implementation specification adopted in § 170.215(c)(3).</P>
                        <P>
                            (10) 
                            <E T="03">SMART clinician access for EHR launch.</E>
                             For the time period up to and including December 31, 2025, a Health IT Module must meet either the requirements specified in paragraph (j)(10)(i)(A), (B), or (C) of this section. For the time period up to and including December 31, 2027, a Health IT Module must meet either the requirements specified in paragraph (j)(10)(i)(B) or (C) of this section. On and after January 1, 2028, a Health IT Module must meet the requirements specified in paragraph (j)(10)(i)(C) of this section.
                        </P>
                        <P>
                            (i) 
                            <E T="03">User authorization.</E>
                             Support user authorization according to the requirements in paragraphs (j)(6)(i) through (iii) of this section, including 
                            <PRTPAGE P="63793"/>
                            support for one of the following sets of SMART capabilities:
                        </P>
                        <P>(A) Support the “Clinician Access for EHR Launch” Capability Set as well as the capabilities of “launch-ehr,” “context-banner,” “context-style,” and “context-ehr-patient” as well as the capabilities in subsections “Client Types,” “Single Sign-on,” and “Permissions” according to the implementation specification adopted in § 170.215(c)(1).</P>
                        <P>(B) Support the “Clinician Access for EHR Launch” Capability Set as well as the capabilities of “launch-ehr,” “context-banner,” “context-style,” “context-ehr-patient,” and “context-ehr-encounter,” and the capabilities in subsections “Authorization Methods,” “Client Types,” “Single Sign-on,” and “Permissions” except the “permission-online” capability according to the implementation specification adopted in § 170.215(c)(2).</P>
                        <P>(C) Support the “Clinician Access for EHR Launch” Capability Set as well as the capabilities of “launch-ehr,” “context-banner,” “context-style,” “context-ehr-patient,” and “context-ehr-encounter,” and the capabilities in subsections “Authorization Methods,” “Client Types,” “Single Sign-on,” and “Permissions” except the “permission-online” capability according to the implementation specification adopted in § 170.215(c)(3).</P>
                        <P>
                            (ii) 
                            <E T="03">User authorization revocation.</E>
                             Support user authorization revocation according to the requirements in paragraph (j)(6)(iv) of this section.
                        </P>
                        <P>
                            (11) 
                            <E T="03">Asymmetric certificate-based authentication for B2B user access.</E>
                             Support asymmetric certificate-based authentication for the “authorization_code” grant type during the process of granting access to patient data to users according to the implementation specifications adopted in § 170.215(o), including support for asymmetric certificate-based authentication as detailed in section “Business-to-Business” of the implementation specifications adopted in § 170.215(o).
                        </P>
                        <P>(12)-(19) [Reserved]</P>
                        <P>
                            (20) 
                            <E T="03">Workflow triggers for decision support interventions—clients.</E>
                             Support the requirements of the implementation specification in § 170.215(f) as a “CDS Client” including support for the following:
                        </P>
                        <P>
                            (i) 
                            <E T="03">Registration.</E>
                             Support registration of CDS Services according to at least one of the implementation specifications in § 170.215(f).
                        </P>
                        <P>
                            (ii) 
                            <E T="03">Authentication and authorization.</E>
                             Support authentication and authorization according to the implementation specification in § 170.215(f)(1).
                        </P>
                        <P>
                            (iii) 
                            <E T="03">Workflow triggers.</E>
                             Support the execution of decision support workflow triggers in accordance with the implementation specification in § 170.215(f)(1).
                        </P>
                        <P>
                            (iv) 
                            <E T="03">Information exchange.</E>
                             Send a decision support request to a CDS Service according to the implementation specification in § 170.215(f)(1), including support for the following:
                        </P>
                        <P>
                            (A) 
                            <E T="03">Pre-fetch.</E>
                             Support the ability to deliver a CDS Hook request with prefetched information according to the “Prefetch Template” section of the implementation specification in § 170.215(f)(1).
                        </P>
                        <P>
                            (B) 
                            <E T="03">Resource access via API.</E>
                             Support access to HL7 FHIR Resources via a RESTful API to support decision support intervention workflows according to the “FHIR Resource Access” section of the implementation specification in § 170.215(f)(1).
                        </P>
                        <P>
                            (C) 
                            <E T="03">Receive and display response.</E>
                             Support the receipt of a decision support response according to the implementation specification in § 170.215(f)(1), including support for the following:
                        </P>
                        <P>
                            (
                            <E T="03">1</E>
                            ) 
                            <E T="03">Display to the end user.</E>
                             Support the display of the contents of a decision support response to an end-user.
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) 
                            <E T="03">SMART app launch.</E>
                             Support the ability to launch internal apps and SMART apps from decision support responses according to the implementation specification in § 170.215(f)(1), including support for the “Link” field “appContext.”
                        </P>
                        <P>
                            (21) 
                            <E T="03">Workflow triggers for decision support interventions—services.</E>
                             Support the requirements of the implementation specification in § 170.215(f)(1) as a “CDS Service” including support for the following:
                        </P>
                        <P>
                            (i) 
                            <E T="03">Registration.</E>
                             Support registration of CDS Clients according to the implementation specification in § 170.215(f)(1).
                        </P>
                        <P>
                            (ii) 
                            <E T="03">Authentication and authorization.</E>
                             Support authentication and authorization according to the implementation specification in § 170.215(f)(1).
                        </P>
                        <P>
                            (iii) 
                            <E T="03">Information exchange to support decision support.</E>
                             Respond to requests for recommendations and guidance via a RESTful API according to the implementation specification in § 170.215(f)(1), including support for the following:
                        </P>
                        <P>
                            (A) 
                            <E T="03">Receive and process decision support request.</E>
                             Receive and process decision support request according to the implementation specification in § 170.215(f)(1), including:
                        </P>
                        <P>
                            (
                            <E T="03">1</E>
                            ) The ability to receive pre-fetched information according to the “Prefetch Template” section of the implementation specification in § 170.215(f)(1); and
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) The ability to fetch HL7 FHIR Resources via an API according to the “FHIR Resource Access” section of the implementation specification in § 170.215(f)(1).
                        </P>
                        <P>
                            (B) 
                            <E T="03">Decision support response.</E>
                             Support returning a decision support response according to the implementation specification in § 170.215(f), including support for the “Link” field “appContext.”
                        </P>
                        <P>
                            (22) 
                            <E T="03">Verifiable health records.</E>
                             Support the issuance of verifiable health records for vaccination status and infectious disease-related laboratory testing according to implementation specifications adopted in § 170.215(g)(1)(i) through (2)(i), including support for the following:
                        </P>
                        <P>
                            (i) 
                            <E T="03">Information profiles.</E>
                             Support the “data minimization” and “allowable data” profiles of the following according to the implementation specification adopted in § 170.215(g)(2)(i): “Immunization Bundle,” “COVID-19 Labs Bundle,” and “Generic Labs Bundle,” “Patient—United States,” “Vaccination,” “Lab results—COVID-19-,” and “Lab results—Generic.”
                        </P>
                        <P>
                            (ii) 
                            <E T="03">API.</E>
                             Support the “$health-cards-issue” operation via a standardized API according to the implementation specification adopted in § 170.215(g)(1).
                        </P>
                        <P>
                            (23) 
                            <E T="03">Subscriptions—server.</E>
                             Support subscriptions as a server according to the implementation specifications in § 170.215(h)(1), including:
                        </P>
                        <P>(i) Support the requirements in section “1.6 Topic-Based Subscriptions—FHIR R4” of the implementation specification in § 170.215(h)(1).</P>
                        <P>(ii) Support the “R4/B Topic-Based Subscription” profile according to the implementation specification in § 170.215(h)(1).</P>
                        <P>(iii) Support the requirements included in the “R4 Topic-Based Subscription Server Capability Statement” of the implementation specification in § 170.215(h)(1), including support for “create,” “update,” and “delete” interactions for HL7 FHIR Subscription Resources according to the implementation specification in § 170.215(h)(1).</P>
                        <P>(iv) Send subscription notifications to subscribed clients according to section “1.6 Topic-Based Subscriptions—FHIR R4” of the implementation specification in § 170.215(h)(1), including:</P>
                        <P>(A) Support for “id-only” Payload Types as specified in the “Payload Types” section of the implementation specification in § 170.215(h)(1).</P>
                        <P>
                            (B) Support for the “REST-Hook” channel as specified in the “Channels” 
                            <PRTPAGE P="63794"/>
                             section of the implementation specification in § 170.215(h)(1).
                        </P>
                        <P>(v) Support the following subscription topics and parameters:</P>
                        <P>
                            (A) 
                            <E T="03">USCDI change notifications.</E>
                             Support the ability for a client to subscribe to notifications filtered by a patient identifier and send notifications when any of the Resources specified in § 170.315(j)(23)(v)(B) are created or updated as applicable according to the standard in § 170.215(a) and implementation specification in § 170.215(h)(1).
                        </P>
                        <P>
                            (B) 
                            <E T="03">Resource notifications.</E>
                             Support the ability for a client to subscribe to notifications filtered according to the conditions below and send notifications for the following Resource interactions according to the standard in § 170.215(a) and implementation specification in § 170.215(h)(1):
                        </P>
                        <P>
                            (
                            <E T="03">1</E>
                            ) “AllergyIntolerance” Resource is created or updated, including support for filtering subscription notifications using “category,” “code,” and “patient” data elements.
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) “CarePlan” Resource is created or updated, including support for filtering subscription notifications using “category” and “subject” data elements.
                        </P>
                        <P>
                            (
                            <E T="03">3</E>
                            ) “CareTeam” Resource is created, or updated, including support for filtering subscription notifications using “category” and “subject” data elements.
                        </P>
                        <P>
                            (
                            <E T="03">4</E>
                            ) “Condition” Resource is created or updated, including support for filtering subscription notifications using “category,” “code,” and “subject” data elements.
                        </P>
                        <P>
                            (
                            <E T="03">5</E>
                            ) “Coverage” Resource is created or updated, including support for filtering subscription notifications using “beneficiary” and “type” data elements.
                        </P>
                        <P>
                            (
                            <E T="03">6</E>
                            ) “DiagnosticReport” Resource is created or updated, including support for filtering subscription notifications using “category,” “code,” and “subject” data elements.
                        </P>
                        <P>
                            (
                            <E T="03">7</E>
                            ) “DocumentReference” Resource is created or updated, including support for filtering subscription notifications using “subject” and “type” data elements.
                        </P>
                        <P>
                            (
                            <E T="03">8</E>
                            ) “Encounter” Resource is created or updated, including support for filtering subscription notifications using “reasonCode,” “subject,” and “type” data elements.
                        </P>
                        <P>
                            (
                            <E T="03">9</E>
                            ) “Goal” Resource is created or updated, including support for filtering subscription notifications using “category,” “description,” and “subject” data elements.
                        </P>
                        <P>
                            (
                            <E T="03">10</E>
                            ) “Immunization” Resource is created or updated, including support for filtering subscription notifications using “patient,” and “vaccineCode” data elements.
                        </P>
                        <P>
                            (
                            <E T="03">11</E>
                            ) “MedicationDispense” Resource is created or updated, including support for filtering subscription notifications using “category,” “medication[x],” and “subject” data elements.
                        </P>
                        <P>
                            (
                            <E T="03">12</E>
                            ) “MedicationRequest” Resource is created or updated, including support for filtering subscription notifications using “category,” “medication[x],” and “subject” data elements.
                        </P>
                        <P>
                            (
                            <E T="03">13</E>
                            ) “Observation” Resource is created or updated, including support for filtering subscription notifications using “category,” “code,” and “subject” data elements.
                        </P>
                        <P>
                            (
                            <E T="03">14</E>
                            ) “Patient” Resource is updated, including support for filtering subscription notifications using the “identifier” data element.
                        </P>
                        <P>
                            (
                            <E T="03">15</E>
                            ) “Procedure” Resource is created or updated, including support for filtering subscription notifications using “category,” “code,” and “subject” data elements.
                        </P>
                        <P>
                            (
                            <E T="03">16</E>
                            ) “QuestionnaireResponse” Resource is created or updated, including support for filtering subscription notifications using the “subject” data element.
                        </P>
                        <P>
                            (
                            <E T="03">17</E>
                            ) “RelatedPerson” Resource is created or updated, including support for filtering subscription notifications using the “patient” data element.
                        </P>
                        <P>
                            (
                            <E T="03">18</E>
                            ) “ServiceRequest” Resource is created or updated, including support for filtering subscription notifications using “category,” “code,” and “subject” data elements.
                        </P>
                        <P>
                            (
                            <E T="03">19</E>
                            ) “Specimen” Resource is created or updated, including support for filtering subscription notifications using “patient” and “type” data elements.
                        </P>
                        <P>
                            (24) 
                            <E T="03">Subscriptions—client.</E>
                             Support subscriptions as a client according to the implementation specifications in § 170.215(h)(1), including:
                        </P>
                        <P>(i) Support the requirements in section “1.6 Topic-Based Subscriptions—FHIR R4” of the implementation specifications in § 170.215(h)(1).</P>
                        <P>(ii) Support the “R4/B Topic-Based Subscription” profile according to the implementation specifications in § 170.215(h)(1).</P>
                        <P>(iii) Support the accompanying client capabilities for the minimum requirements included in the “R4 Topic-Based Subscription Server Capability Statement” of the implementation specification in § 170.215(h)(1), including support for “create,” “update,” and “delete” interactions for HL7 FHIR Subscription Resources according to the implementation specification in § 170.215(h)(1).</P>
                        <P>(iv) Receive subscription notifications according to section “1.6 Topic-Based Subscriptions—FHIR R4” of the implementation specifications in § 170.215(h)(1), including:</P>
                        <P>(A) Support for “id-only” Payload Types as specified in the “Payload Types” section of the implementation specifications in § 170.215(h)(1).</P>
                        <P>(B) Support for consuming notifications via the “REST-Hook” channel as specified in the “Channels” section of the implementation specifications in § 170.215(h)(1).</P>
                    </SECTION>
                    <AMDPAR>11. Amend § 170.402 by adding paragraph (b)(2)(iii) to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 170.402</SECTNO>
                        <SUBJECT>Assurances.</SUBJECT>
                        <P>(b) * * *</P>
                        <P>(2) * * *</P>
                        <P>(iii) On and after January 1, 2028, a health IT developer of a Health IT Module certified to the certification criterion in § 170.315(b)(10) and meets the requirements of § 170.315(b)(10)(i)(F) must:</P>
                        <P>(A) Report to its ONC-ACB no later than March 1 of each calendar year how many requests it received during the immediately preceding calendar year; and</P>
                        <P>(B) Provide all of its customers of that Health IT Module with an updated version of the Health IT Module fully compliant with § 170.315(b)(10)(i)(A) through (F) no later than the end of the second calendar year following the calendar year in which the developer has received more than 10 requests for a single patient export from that Health IT Module.</P>
                    </SECTION>
                    <AMDPAR>12. Amend § 170.404 by:</AMDPAR>
                    <AMDPAR>a. Revising the introductory text;</AMDPAR>
                    <AMDPAR>b. Revising and republishing paragraph (a)(2);</AMDPAR>
                    <AMDPAR>c. Revising paragraphs (b)(1) through (3); and</AMDPAR>
                    <AMDPAR>d. Revising the definitions of “Certified API Developer” and “Certified API technology”.</AMDPAR>
                    <P>The revisions and republication read as follows:</P>
                    <SECTION>
                        <SECTNO>§ 170.404</SECTNO>
                        <SUBJECT>Application programming interfaces.</SUBJECT>
                        <P>The following Condition and Maintenance of Certification requirements apply to developers of Health IT Modules certified to any of the certification criteria adopted in § 170.315(g)(7) through (10), (20), and (30) through (36), and (j), unless otherwise specified in this section.</P>
                        <P>(a) * * *</P>
                        <P>
                            (2) 
                            <E T="03">Transparency conditions</E>
                            —A Certified API Developer must publish complete business and technical documentation, including the documentation described in paragraphs (a)(2)(i) and (ii) of this section, via a publicly accessible hyperlink that 
                            <PRTPAGE P="63795"/>
                            allows any person to directly access the information without any preconditions or additional steps.
                        </P>
                        <P>
                            (i) 
                            <E T="03">Technical documentation.</E>
                             The API(s) must include complete accompanying technical documentation that contains, as applicable:
                        </P>
                        <P>(A) API syntax, function names, required and optional parameters supported and their data types, return variables and their types/structures, exceptions and exception handling methods and their returns.</P>
                        <P>(B) The software components and configurations that would be necessary for an application to implement in order to be able to successfully interact with the API and process its response(s).</P>
                        <P>(C) All applicable technical requirements and attributes necessary for an application to be registered with a Health IT Module's authorization server.</P>
                        <P>
                            (ii) 
                            <E T="03">Terms and conditions.</E>
                             The API(s) must include complete accompanying business documentation that contains, at a minimum:
                        </P>
                        <P>
                            (A) 
                            <E T="03">Material information.</E>
                             A Certified API Developer must publish all terms and conditions for its certified API technology, including any fees, restrictions, limitations, obligations, registration process requirements, or other similar requirements that would be:
                        </P>
                        <P>
                            (
                            <E T="03">1</E>
                            ) Needed to develop software applications to interact with the certified API technology;
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) Needed to distribute, deploy, and enable the use of software applications in production environments that use the certified API technology;
                        </P>
                        <P>
                            (
                            <E T="03">3</E>
                            ) Needed to use software applications, including to access, exchange, and use electronic health information by means of the certified API technology;
                        </P>
                        <P>
                            (
                            <E T="03">4</E>
                            ) Needed to use any electronic health information obtained by means of the certified API technology;
                        </P>
                        <P>
                            (
                            <E T="03">5</E>
                            ) Used to verify the authenticity of API Users; and
                        </P>
                        <P>
                            (
                            <E T="03">6</E>
                            ) Used to register software applications.
                        </P>
                        <P>
                            (B) 
                            <E T="03">API fees.</E>
                             Any and all fees charged by a Certified API Developer for the use of its certified API technology must be described in detailed, plain language. The description of the fees must include all material information, including but not limited to:
                        </P>
                        <P>
                            (
                            <E T="03">1</E>
                            ) The persons or classes of persons to whom the fee applies;
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) The circumstances in which the fee applies; and
                        </P>
                        <P>
                            (
                            <E T="03">3</E>
                            ) The amount of the fee, which for variable fees must include the specific variable(s) and methodology(ies) that will be used to calculate the fee.
                        </P>
                        <STARS/>
                        <P>(b) * * *</P>
                        <P>
                            (1) 
                            <E T="03">Authenticity verification and registration for production use.</E>
                             The following apply to a Certified API Developer with a Health IT Module certified to one or more of § 170.315(g)(10), (20), (30), and (32) through (35):
                        </P>
                        <P>
                            (i) 
                            <E T="03">Authenticity verification.</E>
                             A Certified API Developer is permitted to institute a process to verify the authenticity of API Users so long as such process is objective and the same for all API Users and completed within ten business days of receipt of an API User's request to register their software application for use with the Certified API Developer's Health IT Module certified to any of the criteria in § 170.315(g)(10), (20), (30), and (32) through (35). This process shall not apply to API Users that are part of a trust community supported at an API Information Source deployment submitting registration requests conformant to the specifications in § 170.215(o).
                        </P>
                        <P>
                            (ii) 
                            <E T="03">Registration for production use.</E>
                             A Certified API Developer must register and enable all applications for production use within five business days of completing its verification of an API User's authenticity, pursuant to paragraph (b)(1)(i) of this section. If the API User is part of a trust community supported at an API Information Source deployment and submitted a valid registration request conformant to the specifications in § 170.215(o), then the application must instead be enabled for production use within one business day.
                        </P>
                        <P>
                            (2) 
                            <E T="03">Publication of API discovery details for patient access.</E>
                             For the time period up to and including December 31, 2027, Certified API Developers with Health IT Modules certified to § 170.315(g)(10) must meet either the API discovery detail requirements in paragraphs (b)(2)(i) and (ii) of this section or the requirements in (b)(2)(i), (iii), and (iv) of this section. On and after January 1, 2028, all Certified API Developers with Health IT Modules certified to § 170.315(g)(10) must meet the requirements in (b)(2)(i), (iii), and (iv) of this section. Certified API Developers with Health IT Modules certified to § 170.315(g)(30) must meet the requirements in paragraphs (b)(2)(i), (iii), and (iv) of this section.
                        </P>
                        <P>
                            (i) 
                            <E T="03">API discovery terms.</E>
                             API discovery details in paragraphs (b)(2)(ii), (iii), and (iv) of this section must be published and reviewed according to the following terms:
                        </P>
                        <P>(A) Publicly published, at no charge, for all its customers regardless of whether the Health IT Module is centrally managed by the Certified API Developer or locally deployed by an API Information Source.</P>
                        <P>(B) Reviewed quarterly and as necessary updated.</P>
                        <P>
                            (ii) 
                            <E T="03">API discovery in FHIR format.</E>
                             API discovery details must be published in the following formats in accordance with the standards in § 170.215(a):
                        </P>
                        <P>(A) Service base URLs must be publicly published in the Endpoint resource format.</P>
                        <P>(B) Organization details for each service base URL must be publicly published in the Organization resource format. Each Organization resource must contain:</P>
                        <P>
                            (
                            <E T="03">1</E>
                            ) A reference, in the Organization.endpoint element, to the Endpoint resources containing service base URLs managed by this organization.
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) The organization's name, location, and facility identifier.
                        </P>
                        <P>(C) Endpoint and Organization resources must be collected into a Bundle resource format.</P>
                        <P>
                            (iii) 
                            <E T="03">API discovery in user-access brand format.</E>
                             API discovery details and related API Information Source details, including the API Information Source's name, location, and facility identifier, must be publicly published in an aggregate vendor-consolidated Bundle according to the “User-access Brands and Endpoints” specification in at least one implementation specification adopted in § 170.215(c).
                        </P>
                        <P>
                            (iv) 
                            <E T="03">Trust community discovery for dynamic registration.</E>
                             Trust community details such as trust community name, contact information, web address, and identifying Uniform Resource Identifier (URI) must be publicly published in a computable format at no charge for each service base URL published in accordance with (b)(2)(iii) of this section.
                        </P>
                        <P>
                            (3) 
                            <E T="03">Publication of API discovery details for payer information.</E>
                             A Certified API Developer certified to § 170.315(g)(32), (33), (35), or (36) must conform to the following:
                        </P>
                        <P>(i) The Certified API Developer must publicly publish API discovery details for all of its customers with Health IT Modules certified to § 170.315(g)(30), (32), (33), (35), or (36) regardless of whether the Health IT Modules are centrally managed by the Certified API Developer or locally deployed by an implementer of the certified API technology;</P>
                        <P>
                            (ii) The API Information Source details, including the API Information Source's name and location, must be 
                            <PRTPAGE P="63796"/>
                            published in an aggregate vendor-consolidated Bundle according to the “User-access Brands and Endpoints” specification in at least one implementation specification adopted in § 170.215(c); and
                        </P>
                        <P>(iii) All API discovery details for payer information published according to this section must be reviewed quarterly and, as necessary, updated by the Certified API Developer.</P>
                        <STARS/>
                        <P>(c) * * *</P>
                        <P>
                            <E T="03">Certified API Developer</E>
                             means a health IT developer that creates “certified API technology.”
                        </P>
                        <P>
                            <E T="03">Certified API technology</E>
                             means the capabilities of Health IT Modules that are certified to any of the API-focused certification criteria adopted in § 170.315(g)(7) through (10), (20), and (30) through (36), and (j).
                        </P>
                        <STARS/>
                    </SECTION>
                    <AMDPAR>13. Amend § 170.405 by revising paragraph (a) to read as follows.</AMDPAR>
                    <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 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), (g)(20) and (30) through (36), (h), and (j) 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>
                        <STARS/>
                    </SECTION>
                    <AMDPAR>14. Amend § 170.406 by revising paragraph (a)(2) to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 170.406</SECTNO>
                        <SUBJECT>Attestations.</SUBJECT>
                        <P>(a) * * *</P>
                        <P>(2) Section 170.402, but only for § 170.402(a)(4) and (b)(2) if the health IT developer certified a Health IT Module(s) that is part of a health IT product which can store electronic health information; and, § 170.402(b)(4) if the health IT developer certified a Health IT Module(s) to § 170.315(b)(11).</P>
                        <STARS/>
                    </SECTION>
                    <AMDPAR>15. Amend § 170.407 by revising and republishing paragraphs (a)(1), (2), (a)(3)(i) and (ii), and (b) 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 available via a publicly accessible hyperlink, related to the data sources and methodology used to generate measures;</P>
                        <P>
                            (C) Percentage of total customers (
                            <E T="03">e.g.,</E>
                             hospitals, individual clinician users) represented in provided data; and
                        </P>
                        <P>
                            (D) Health care provider identifiers (
                            <E T="03">e.g.,</E>
                             National Provider Identifier (NPI), CMS Certification Number (CCN), or health system ID) for providers included in the 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 hospitals 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) themselves or through their authorized representatives overall and by different methods of access through certified health IT.
                        </P>
                        <P>
                            (ii) 
                            <E T="03">C-CDA 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);</P>
                        <P>(D) C-CDA documents reconciled and incorporated both through manual and automated processes; and</P>
                        <P>(E) Specific data classes and elements from C-CDA documents reconciled and incorporated both through manual and automated processes.</P>
                        <STARS/>
                        <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:
                        </P>
                        <P>(i) A health IT developer must provide responses for measures specified in:</P>
                        <P>(A) Paragraphs (a)(3)(i) and (iii), (a)(3)(iv)(A) and (B), and (a)(3)(vi) of this section beginning July 2027;</P>
                        <P>(B) Paragraphs (a)(3)(ii)(A) through (C), (a)(3)(iv)(C), (a)(3)(v), (a)(3)(vi)(A) and (B), and (a)(3)(vii) of this section beginning July 2028;</P>
                        <P>(C) Paragraphs (a)(3)(ii)(D) and (a)(3)(vii)(A) of this section beginning July 2029; and</P>
                        <P>(D) Paragraph (a)(3)(ii)(E) of this section beginning July 2030.</P>
                        <P>(ii) A health IT developer must provide responses applicable to all their certified health IT that meet the requirements specified in paragraph (a) of this section as of January 1st of the year prior in which the responses are submitted.</P>
                        <P>(2) For certified Health IT Modules included in paragraph (a) of this section that are updated using Inherited Certified Status after January 1 of the year prior in which the responses are submitted, a health IT developer must include the newer version of the certified Health IT Module(s) in its annual responses to the Insights Condition of Certification.</P>
                    </SECTION>
                    <AMDPAR>16. Amend § 170.502 by revising the definition of “Gap certification” to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 170.502</SECTNO>
                        <SUBJECT>Definitions.</SUBJECT>
                        <STARS/>
                        <P>
                            <E T="03">Gap certification</E>
                             means the certification of a previously certified Health IT Module(s) to:
                        </P>
                        <P>(1) All applicable new and/or revised certification criteria adopted by the Secretary at subpart C of this part based on test results issued by a NVLAP-accredited testing laboratory under the ONC Health IT Certification Program or an ONC-ATL; and</P>
                        <P>(2) All other applicable certification criteria adopted by the Secretary at subpart C of this part based on the test results used to previously certify the Health IT Module(s) under the ONC Health IT Certification Program.</P>
                        <STARS/>
                    </SECTION>
                    <AMDPAR>17. Amend § 170.505 by revising paragraph (a)(2) to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 170.505</SECTNO>
                        <SUBJECT>Correspondence</SUBJECT>
                        <P>(a) * * *</P>
                        <P>
                            (2) The applicant for ONC-ATL status, the applicant for ONC-ACB status, an ONC-ACB, an ONC-ATL, health IT developer, or a party to any proceeding under this subpart will be considered to have received 
                            <PRTPAGE P="63797"/>
                            correspondence or other written communication from ONC or the National Coordinator on the first of the following:
                        </P>
                        <P>(i) The date on which ONC or the National Coordinator receives a response to the correspondence via written or verbal communication methods;</P>
                        <P>(ii) The date of the delivery confirmation to the address on record for correspondence sent by express or certified mail; or</P>
                        <P>(iii) The date of the seventh business day (as defined in § 170.102) after the date on which the email, express, or certified mail was sent.</P>
                        <STARS/>
                    </SECTION>
                    <AMDPAR>18. Revise § 170.511 to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 170.511</SECTNO>
                        <SUBJECT>Authorization scope for ONC-ATL status.</SUBJECT>
                        <P>Applicants may seek authorization from the National Coordinator to perform the testing of Health IT Modules to a portion of a certification criterion, one certification criterion, or many or all certification criteria adopted by the Secretary under subpart C of this part.</P>
                    </SECTION>
                    <AMDPAR>19. Amend § 170.523 by:</AMDPAR>
                    <AMDPAR>a. Revising paragraph (i)(2)(iii),</AMDPAR>
                    <AMDPAR>b. Adding paragraph (i)(4);</AMDPAR>
                    <AMDPAR>c. Revising paragraphs (j)(3) and (m)(3) through (5);</AMDPAR>
                    <AMDPAR>d. Adding paragraph (m)(6);</AMDPAR>
                    <AMDPAR>e. Redesignating paragraphs (p) through (u) as paragraphs (r) through (w);</AMDPAR>
                    <AMDPAR>f. Adding new paragraphs (p) and (q); and</AMDPAR>
                    <AMDPAR>g. Add paragraphs (x) and (y).</AMDPAR>
                    <P>The revisions and additions read as follows:</P>
                    <SECTION>
                        <SECTNO>§ 170.523</SECTNO>
                        <SUBJECT>Principles of proper conduct for ONC-ACBs.</SUBJECT>
                        <STARS/>
                        <P>(i) * * *</P>
                        <P>(1) * * *</P>
                        <P>(2) * * *</P>
                        <P>(iii) Certification criteria, Maintenance of Certification, and other ONC Health IT Certification Program requirements surveilled;</P>
                        <STARS/>
                        <P>(4) Notify the National Coordinator prior to initiating a suspension in accordance with § 170.556(d)(5) or withdraw certification in accordance with § 170.556(d)(6) for a Health IT Module for a non-conformity pertaining to a Maintenance of Certification requirement for which the ONC-ACBs have responsibilities in this section.</P>
                        <STARS/>
                        <P>(j) * * *</P>
                        <P>(3) Previous certifications that it performed if its conduct necessitates the recertification of Health IT Module(s);</P>
                        <STARS/>
                        <P>(m) * * *</P>
                        <P>(3) All use cases for § 170.315(d)(13), for the time period up to and including December 31, 2027;</P>
                        <P>(4) All updates made to certified Health IT Modules in compliance with § 170.405(b)(3);</P>
                        <P>(5) All updates to certified Health IT Modules and all certifications of Health IT Modules issued including voluntary use of newer standards versions per § 170.405(b)(8) or (9). Record of these updates may be obtained by aggregation of ONC-ACB documentation of certification activity; and</P>
                        <P>(6) On and after January 1, 2027, all updates to API discovery details for § 170.404(b)(2) and (3).</P>
                        <STARS/>
                        <P>
                            (p) 
                            <E T="03">Assurances.</E>
                             (1) Confirm that health IT developers retain all records and information necessary to demonstrate initial and ongoing compliance with the requirements of the ONC Health IT Certification Program in accordance with § 170.402(b)(1).
                        </P>
                        <P>(2) Confirm that applicable health IT developers update the Health IT Module and provide the updated Health IT Module within the specified timeframes in accordance with § 170.402(b)(2) and (3).</P>
                        <P>(3) Confirm that applicable health IT developers comply with the predictive decision support intervention transparency requirements in accordance with § 170.402(b)(4).</P>
                        <P>
                            (q) 
                            <E T="03">Application programming interfaces.</E>
                             (1) Confirm that applicable health IT developers comply with the authenticity verification and registration for production use requirements for application programming interface Maintenance of Certification requirements in accordance with § 170.404(b)(1).
                        </P>
                        <P>(2) Confirm that applicable health IT developers publish API discovery details for all Health IT Modules certified to § 170.315(g)(10) and (30) in accordance with § 170.404(b)(2).</P>
                        <P>
                            (r) 
                            <E T="03">Real world testing.</E>
                             (1) Review and confirm that applicable health IT developers submit real world testing plans in accordance with § 170.405(b)(1).
                        </P>
                        <P>(2) Review and confirm that applicable health IT developers submit real world testing results in accordance with § 170.405(b)(2).</P>
                        <P>(3) Submit real world testing plans by December 15 of each calendar year and results by March 15 of each calendar year to ONC for public availability.</P>
                        <P>
                            (s) 
                            <E T="03">Attestations.</E>
                             Review and submit health IT developer Conditions and Maintenance of Certification requirements attestations made in accordance with § 170.406 to ONC for public availability.
                        </P>
                        <P>
                            (t) 
                            <E T="03">Test results from ONC-ATLs.</E>
                             Accept test results from any ONC-ATL that is:
                        </P>
                        <P>(1) In good standing under the ONC Health IT Certification Program, and</P>
                        <P>(2) Compliant with its ISO/IEC 17025 accreditation requirements as required by 170.524(a).</P>
                        <P>
                            (u) 
                            <E T="03">Information for direct review.</E>
                             Report to ONC, no later than a week after becoming aware of, any information that could inform whether ONC should exercise direct review under § 170.580(a).
                        </P>
                        <P>
                            (v) 
                            <E T="03">Health IT Module voluntary standards and implementation specifications updates notices.</E>
                             Ensure health IT developers opting to take advantage of the flexibility for voluntary updates of standards and implementation specifications in certified Health IT Modules per § 170.405(b)(8) provide timely advance written notice to the ONC-ACB and all affected customers.
                        </P>
                        <P>(1) Maintain a record of the date of issuance and the content of developers' § 170.405(b)(8) notices; and</P>
                        <P>(2) Timely post content or make publicly accessible via the CHPL each § 170.405(b)(8) notice received, publicly on the CHPL attributed to the certified Health IT Module(s) to which it applies.</P>
                        <P>
                            (w) 
                            <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>
                        <P>
                            (x) 
                            <E T="03">Reporting for non-compliance with approved corrective action plans.</E>
                             Report to ONC, pursuant to paragraph § 170.556(d)(7)(ii) of this subpart, the developer's failure to timely complete a corrective action plan specific to a Maintenance of Certification requirement for which an ONC-ACB has specific responsibilities under this section. The ONC-ACB must include all documentation pertaining to the identified non-conformity, including the following information:
                        </P>
                        <P>(1) The Health IT Module and associated product(s);</P>
                        <P>(2) The nature of the non-conformity(ies);</P>
                        <P>(3) The corrective action plan documentation;</P>
                        <P>(4) Communications and records of proceedings; and</P>
                        <P>
                            (5) Any additional information requested by ONC.
                            <PRTPAGE P="63798"/>
                        </P>
                        <P>
                            (y) 
                            <E T="03">Authorization withdrawal notice.</E>
                             Provide ONC notice of intent to withdraw its authorization from the Certification Program:
                        </P>
                        <P>(1) Submit written notice to ONC 180 days prior to the withdrawal date.</P>
                        <P>(2) Submit all records to ONC related to the certification of Health IT Modules required by paragraph (g) of this section.</P>
                    </SECTION>
                    <AMDPAR>20. 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 from the effective date of the removal of those certification criteria from the Code of Federal Regulations; and</P>
                        <STARS/>
                    </SECTION>
                    <AMDPAR>21. Amend § 170.550 by:</AMDPAR>
                    <AMDPAR>a. Adding paragraph (g)(6);</AMDPAR>
                    <AMDPAR>b. Revising paragraphs (h)(1),</AMDPAR>
                    <AMDPAR>c. Revising and republishing paragraph (h)(3);</AMDPAR>
                    <AMDPAR>d. Adding paragraph (h)(4); and</AMDPAR>
                    <AMDPAR>e. Removing and reserving paragraph (m).</AMDPAR>
                    <P>The additions, revisions, and republication read as follows:</P>
                    <SECTION>
                        <SECTNO>§ 170.550</SECTNO>
                        <SUBJECT>Health IT Module certification.</SUBJECT>
                        <STARS/>
                        <P>(g) * * *</P>
                        <P>(6) Section 170.315(b)(4) if the Health IT Module is presented for certification to the certification criteria in § 170.315(b)(3).</P>
                        <P>(h) * * *</P>
                        <P>(1) When certifying a Health IT Module to the ONC Certification Criteria for Health IT, an ONC-ACB can only issue a certification to a Health IT Module if the privacy and security certification criteria in paragraphs (h)(3)(i) through (xii) of this section have also been met (and are included within the scope of the certification).</P>
                        <STARS/>
                        <P>
                            (3) 
                            <E T="03">Applicability.</E>
                             (i) Section 170.315(a)(1) through (3), (5), (12), (14), and (15) are also certified to the certification criteria specified in § 170.315(d)(1) through (7) and (12) and, for the time period up to and including December 31, 2027, (d)(13).
                        </P>
                        <P>(ii) Section 170.315(a)(4), (10), and (13) and, on and after January 1, 2028, (b)(11), are also certified to the certification criteria specified in § 170.315(d)(1) through (3), (5) through (7), and (12) and, for the time period up to and including December 31, 2027, (d)(13).</P>
                        <P>(iii) Section 170.315(b)(1) through (3) and (6) through (9) are also certified to the certification criteria specified in § 170.315(d)(1) through (3),(5) through (8), and (12) and, for the time period up to and including December 31, 2027, (d)(13);</P>
                        <P>(iv) Section 170.315(c) is also certified to the certification criteria specified in § 170.315(d)(1) (d)(2)(i)(A) and (B), (d)(2)(ii) through (v), and (d)(3), (5), and (12) and, for the time period up to and including December 31, 2027, (d)(13);</P>
                        <P>(v) Section 170.315(e)(1) is also certified to the certification criteria specified in § 170.315(d)(1) through (3), (5), (7), (9), and (12) and, for the time period up to and including December 31, 2027, (d)(13);</P>
                        <P>(vi) Section 170.315(e)(2) and (3) are also certified to the certification criteria specified in § 170.315(d)(1), (d)(2)(i)(A) and (B), (d)(2)(ii) through (v), and (d)(3), (5), (9), and (12) and, for the time period up to and including December 31, 2027, (d)(13);</P>
                        <P>(vii) Section 170.315(f) is also certified to the certification criteria specified in § 170.315(d)(1) through (3), (7), and (12) and, for the time period up to and including December 31, 2027, (d)(13);</P>
                        <P>(viii) Section 170.315(g)(7) through (10), (20), and (30) through (36) are also certified to the certification criteria specified in § 170.315(d)(1), (9), and (12) and, for the time period up to and including December 31, 2027, (d)(13); and § 170.315(d)(2)(i)(A) and (B), (d)(2)(ii) through (v), or (d)(10);</P>
                        <P>(ix) Section 170.315(h) is also certified to the certification criteria specified in § 170.315(d)(1), (d)(2)(i)(A) and (B), (d)(2)(ii) through (v), and (d)(3) and (12) and, for the time period up to and including December 31, 2027, (d)(13);</P>
                        <P>(x) Section 170.315(j) is also certified to the certification criteria specified in § 170.315(d)(1), (d)(2)(i)(A) and (B), (d)(2)(ii) through (v), (d)(3), and (12).</P>
                        <P>
                            (4) 
                            <E T="03">Methods to demonstrate compliance with each privacy and security criterion.</E>
                             One of the following methods must be used to meet each applicable privacy and security criterion listed in paragraph (h)(3) of this section:
                        </P>
                        <P>(i) Directly, by demonstrating a technical capability to satisfy the applicable certification criterion or certification criteria; or</P>
                        <P>(ii) Demonstrate, through system documentation sufficiently detailed to enable integration, that the Health IT Module has implemented service interfaces for each applicable privacy and security certification criterion that enable the Health IT Module to access external services necessary to meet the privacy and security certification criterion.</P>
                        <STARS/>
                    </SECTION>
                    <AMDPAR>22. Amend 170.555 by revising paragraph (b)(2) to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 170.555</SECTNO>
                        <SUBJECT>Certification to newer versions of certain standards.</SUBJECT>
                        <STARS/>
                        <P>(b) * * *</P>
                        <P>(2) A certified Health IT Module may be upgraded to comply with newer versions of standards identified as minimum standards in subpart B of this part without adversely affecting its certification status unless the Secretary prohibits the use of a newer version for certification.</P>
                    </SECTION>
                    <AMDPAR>23. Amend § 170.556 by revising and republishing paragraphs (b) and (d) and revising paragraph (e)(3) to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 170.556</SECTNO>
                        <SUBJECT>In-the-field surveillance and maintenance of certification for Health IT.</SUBJECT>
                        <STARS/>
                        <P>
                            (b) 
                            <E T="03">Reactive surveillance.</E>
                             An ONC-ACB must initiate surveillance (including, as necessary, in-the-field surveillance required by paragraph (a) of this section) whenever it becomes aware of facts or circumstances that would cause a reasonable person in the ONC-ACB's position to question one or more of the following in paragraphs (b)(1) through (3) of this section. Additionally, when an ONC-ACB performs reactive surveillance under this paragraph, it must verify that the requirements of § 170.523(k) have been followed as applicable to the issued certification.
                        </P>
                        <P>(1) A certified Health IT Module's continued conformity to the requirements of its certification;</P>
                        <P>(2) A developer's satisfaction of the Maintenance of Certification requirements in § 170.402(b)(1);</P>
                        <P>(3) An applicable developer's satisfaction of the Maintenance of Certification requirements for which an ONC-ACB has a responsibility under § 170.523 to confirm compliance;</P>
                        <STARS/>
                        <P>
                            (d) 
                            <E T="03">Corrective action plan and procedures.</E>
                             (1) When an ONC-ACB determines, through surveillance under this section or otherwise, that a Health IT Module does not conform to the requirements of its certification or that the health IT developer is out of compliance with a Maintenance of Certification requirement specified in subpart D of this part for which the ONC-ACB has specific responsibilities under § 170.523, it must notify the developer of its findings and require the developer to submit a proposed 
                            <PRTPAGE P="63799"/>
                            corrective action plan for the applicable certification criterion, certification criteria, certification requirement, or Maintenance of Certification requirement.
                        </P>
                        <P>(2) The ONC-ACB shall provide direction to the developer as to the required elements of the corrective action plan.</P>
                        <P>(3) The ONC-ACB shall verify the required elements of the corrective action plan as specified in this paragraph.</P>
                        <P>(i) At a minimum, any corrective action plan submitted by a developer to an ONC-ACB must at least include all the following elements for each identified non-conformity:</P>
                        <P>(A) A description of the identified non-conformities;</P>
                        <P>(B) The timeframe under which corrective action will be completed; and</P>
                        <P>(C) An attestation by the developer that it has completed all elements of the approved corrective action plan.</P>
                        <P>(ii) For all identified non-conformities with respect to any Program requirement codified in subpart A, B, C, or E of this part, the corrective action plan must include the following elements, in addition to the elements identified in paragraph (d)(3)(i) of this section:</P>
                        <P>(A) An assessment of how widespread or isolated the identified non-conformities may be across all of the developer's customers and users of the certified Health IT Module;</P>
                        <P>(B) How the developer will address the identified non-conformities, both at any locations where surveillance has identified the non-conformity to have occurred and for all other potentially affected customers and users; and</P>
                        <P>(C) How the developer will ensure that all affected and potentially affected customers and users are alerted to the identified non-conformities, including a detailed description of how the developer will assess the scope and impact of the problem and include identifying all potentially affected customers; how the developer will promptly ensure that all potentially affected customers are notified of the problem and plan for resolution; how and when the developer will resolve issues for individual affected customers; and how the developer will ensure that all issues are in fact resolved.</P>
                        <P>(iii) For all identified non-conformities with respect to any Program requirement codified in subpart D of this part, the corrective action plan must include the following elements, in addition to elements identified in paragraph (d)(3)(i) of this section:</P>
                        <P>(A) How the developer will address the identified non-conformities specific to Maintenance of Certification requirements codified in subpart D of this part; and</P>
                        <P>(B) How the developer will ensure that all identified non-conformities specific to Maintenance of Certification requirements codified in subpart D of this part are resolved.</P>
                        <P>(iv) The ONC-ACB may require the corrective action plan to include elements beyond those specified in this paragraph as the minimum necessary.</P>
                        <P>(4) When the ONC-ACB receives a proposed corrective action plan (or a revised proposed corrective action plan), the ONC-ACB shall either approve the corrective action plan or if the plan does not adequately address the required elements described by paragraph (d)(3) of this section, instruct the developer to submit a revised proposed corrective action plan.</P>
                        <P>(5) For an identified non-conformity with respect to any Program requirement codified in subpart A, B, C, or E of this part or any Program requirement codified in subpart D of this part for which the ONC-ACB has responsibilities under § 170.523, consistent with its accreditation to ISO/IEC 17065 and procedures for suspending a certification, an ONC-ACB shall initiate suspension procedures for a Health IT Module:</P>
                        <P>(i) Thirty (30) days after notifying the developer of a non-conformity pursuant to paragraph (d)(1) of this section, if the developer has not submitted a proposed corrective action plan;</P>
                        <P>(ii) Ninety (90) days after notifying the developer of a non-conformity pursuant to paragraph (d)(1) of this section, if the ONC-ACB cannot approve a corrective action plan because the developer has not submitted a revised proposed corrective action plan in accordance with paragraph (d)(4) of this section; and</P>
                        <P>(iii) Immediately, if the developer has not completed the corrective actions specified by an approved corrective action plan within the time specified therein.</P>
                        <P>(6) If a certified Health IT Module's certification has been suspended, an ONC-ACB is permitted to initiate certification withdrawal procedures for the Health IT Module (consistent with its accreditation to ISO/IEC 17065 and procedures for withdrawing a certification) when the health IT developer has not completed the actions necessary to reinstate the suspended certification.</P>
                        <P>(7) Notification procedures for failure to timely submit a proposed or revised proposed corrective action plan, or complete an approved corrective action plan requirements in subpart D of this part.</P>
                        <P>(i) For an identified non-conformity with respect to any Program requirement codified in subpart D of this part for which the ONC-ACB has responsibilities under § 170.523, consistent with its accreditation to ISO/IEC 17065 and procedures for notifying ONC, an ONC-ACB shall notify the National Coordinator immediately if one or more of the following occurs:</P>
                        <P>(A) The developer has not submitted a proposed corrective action plan within the time specified in paragraph (d)(5) of this section.</P>
                        <P>(B) The ONC-ACB cannot approve a corrective action plan because the developer has not submitted a revised proposed corrective action plan in accordance with paragraph (d)(4) of this section.</P>
                        <P>(C) The developer has not completed the corrective actions specified by an approved corrective action plan within the time specified therein.</P>
                        <P>(ii) When a health IT developer fails to obtain approval for a proposed corrective action plan or to complete an approved corrective action plan with respect to any Program requirement codified in subpart D of this part for which the ONC-ACB has responsibilities under § 170.523, the ONC-ACB shall report the information specified in § 170.523(x) to ONC pursuant to paragraph (d)(7)(i) of this section.</P>
                        <P>(A) The ONC-ACB must notify the developer immediately when the ONC-ACB begins the notification procedures in paragraph (d)(7)(i) of this section.</P>
                        <P>(e) * * *</P>
                        <P>
                            (3) 
                            <E T="03">Reporting of corrective action plans.</E>
                             When a corrective action plan is initiated for a Health IT Module, an ONC-ACB must report the Health IT Module and associated product and corrective action information to the National Coordinator in accordance with § 170.523(f)(1)(xxii) as applicable.
                        </P>
                        <STARS/>
                    </SECTION>
                    <AMDPAR>24. Amend § 170.580 by:</AMDPAR>
                    <AMDPAR>
                        a. Revising paragraphs (a)(3)(iii) and (v), (a)(4)(ii), (b)(2)(ii)(A)(
                        <E T="03">3</E>
                        ), (b)(2)(ii)(B) introductory text, (b)(2)(iii), (c)(1), (c)(2) introductory text, (c)(7), and (d)(1), (2), and (6); and
                    </AMDPAR>
                    <AMDPAR>b. Revising and republishing paragraphs (e), (f), and (g).</AMDPAR>
                    <P>The revisions and republications read as follows:</P>
                    <SECTION>
                        <SECTNO>§ 170.580</SECTNO>
                        <SUBJECT>ONC review of certified health IT.</SUBJECT>
                        <P>(a) * * *</P>
                        <P>(3) * * *</P>
                        <P>
                            (iii) The National Coordinator's determination on matters under ONC 
                            <PRTPAGE P="63800"/>
                            Direct Review is controlling and supersedes any determination by an ONC-ACB on the same matters.
                        </P>
                        <STARS/>
                        <P>(v) The National Coordinator may end all or any part of ONC's review of certified health IT or a health IT developer's actions or practices under this section at any time and refer the applicable part of the review to the relevant ONC-ACB(s) if doing so would serve the effective administration or oversight of the ONC Health IT Certification Program.</P>
                        <P>(4) * * *</P>
                        <P>(ii) The National Coordinator may rely on Office of Inspector General findings to form the basis of a direct review action.</P>
                        <P>(b) * * *</P>
                        <P>(2) * * *</P>
                        <P>(ii) * * *</P>
                        <P>(A) * * *</P>
                        <P>
                            (
                            <E T="03">3</E>
                            ) Providing ONC within 30 days, or within the adjusted timeframe set in accordance with paragraph (b)(2)(ii)(B) of this section, a written explanation and all supporting documentation addressing the non-conformity, clearly labeling as “previously submitted” any documentation previously submitted to ONC in response to paragraph (b)(1)(ii)(A)(
                            <E T="03">3</E>
                            ) of this section, as applicable, and any additional information indicated by ONC.
                        </P>
                        <P>
                            (B) The National Coordinator may decide to shorten the 30-day timeframe specified in paragraph (b)(2)(ii)(A)(
                            <E T="03">3</E>
                            ) of this section where the non-conformity is specific to failure to timely complete a Condition or Maintenance of Certification requirement in any of the requirements in § 170.401 through § 170.407 or may adjust the 30-day timeframe specified in paragraph (b)(2)(ii)(A)(
                            <E T="03">3</E>
                            ) be shorter or longer based on factors including, but not limited to:
                        </P>
                        <STARS/>
                        <P>
                            (iii) 
                            <E T="03">National Coordinator determination.</E>
                             After receiving the health IT developer's response provided in accordance with paragraph (b)(2)(ii) of this section, the National Coordinator shall direct ONC to either issue a written determination ending its review or continue with its review under the provisions of this section.
                        </P>
                        <P>(c) * * *</P>
                        <P>(1) If the National Coordinator determines that certified health IT or a health IT developer's action or practice does not conform to requirements of the ONC Health IT Certification Program, ONC shall notify the health IT developer of its determination and require the health IT developer to submit a proposed corrective action plan.</P>
                        <P>(2) ONC shall provide direction to the health IT developer as to the required elements of the corrective action plan, which shall include such required elements as the National Coordinator determines necessary to comprehensively and expeditiously resolve the identified non-conformity(ies). Each corrective action plan shall include, for each specific non-conformity, all the elements in paragraphs (c)(2)(i) through (viii) except those that are explicitly waived by the National Coordinator:</P>
                        <STARS/>
                        <P>(7) ONC may reinstitute a corrective action plan if the National Coordinator later determines that a health IT developer has not fulfilled all of the developer's obligations under the corrective action plan as attested in accordance with paragraph (c)(6) of this section.</P>
                        <P>(d) * * *</P>
                        <P>(1) ONC may suspend the certification of a Health IT Module at any time if the National Coordinator determines that ONC has a reasonable belief that the certified health IT may present a serious risk to public health or safety.</P>
                        <P>(2) When the National Coordinator decides to suspend a certification, ONC will notify the health IT developer of its determination through a notice of suspension.</P>
                        <STARS/>
                        <P>(6) Any suspension issued under this paragraph (d) may be canceled at any time if:</P>
                        <P>(i) The National Coordinator determines that ONC no longer has a reasonable belief that the certified health IT presents a serious risk to public health or safety; or</P>
                        <P>(ii) The Secretary, who may choose to review National Coordinator determinations under this paragraph at their discretion, directs the National Coordinator to cancel the suspension.</P>
                        <P>(e) Proposed termination. (1) Excluding situations of noncompliance with a Condition or Maintenance of Certification requirement under subpart D of this part, the National Coordinator may propose to terminate a certification issued to a Health IT Module if:</P>
                        <P>(i) The health IT developer fails to timely respond to any communication from ONC, including, but not limited to:</P>
                        <P>(A) Fact-finding;</P>
                        <P>
                            (B) A notice of potential non-conformity within the timeframe established in accordance with paragraph (b)(1)(ii)(A)(
                            <E T="03">3</E>
                            ) of this section;
                        </P>
                        <P>
                            (C) A notice of non-conformity within the timeframe established in accordance with paragraph (b)(2)(ii)(A)(
                            <E T="03">3</E>
                            ) of this section; or
                        </P>
                        <P>(D) A notice of suspension.</P>
                        <P>(ii) The information or access provided by the health IT developer in response to any ONC communication, including, but not limited to: Fact-finding, a notice of potential non-conformity, or a notice of non-conformity is insufficient or incomplete;</P>
                        <P>(iii) The health IT developer fails to cooperate with ONC and/or a third party acting on behalf of ONC;</P>
                        <P>(iv) The health IT developer fails to timely submit in writing a proposed corrective action plan;</P>
                        <P>(v) The health IT developer fails to timely submit a corrective action plan that adequately addresses the elements required by ONC as described in paragraph (c) of this section;</P>
                        <P>(vi) The health IT developer does not fulfill its obligations under the corrective action plan developed in accordance with paragraph (c) of this section; or</P>
                        <P>(vii) The National Coordinator concludes that a certified health IT's non-conformity(ies) cannot be cured.</P>
                        <P>(2) When the National Coordinator decides to propose to terminate a certification, ONC will notify the health IT developer of the proposed termination through a notice of proposed termination.</P>
                        <P>(i) The notice of proposed termination will include, but may not be limited to:</P>
                        <P>(A) An explanation for the proposed termination;</P>
                        <P>(B) Information supporting the proposed termination; and</P>
                        <P>(C) Instructions for responding to the proposed termination.</P>
                        <P>(3) The health IT developer may respond to a notice of proposed termination, but must do so within 10 days of receiving the notice of proposed termination and must include appropriate documentation explaining in writing why its certification should not be terminated.</P>
                        <P>(4) Upon receipt of the health IT developer's written response to a notice of proposed termination, the National Coordinator has up to 30 days to make a determination based on ONC's review of the information submitted by the health IT developer. The National Coordinator may extend this timeframe if the complexity of the case requires additional time for ONC review. ONC will, as applicable:</P>
                        <P>(i) Notify the health IT developer in writing that it has ceased all or part of its review of the health IT developer's certified health IT.</P>
                        <P>(ii) Notify the health IT developer in writing of its intent to continue all or part of its review of the certified health IT under the provisions of this section.</P>
                        <P>
                            (iii) Proceed to terminate the certification of the health IT under 
                            <PRTPAGE P="63801"/>
                            review consistent with paragraph (f) of this section.
                        </P>
                        <P>
                            (f) 
                            <E T="03">Termination.</E>
                             (1) 
                            <E T="03">Applicability.</E>
                             The National Coordinator may terminate a certification if:
                        </P>
                        <P>(i) A determination is made that termination is appropriate after considering the information provided by the health IT developer in response to the proposed termination notice;</P>
                        <P>(ii) The health IT developer does not respond in writing to a proposed termination notice within the timeframe specified in paragraph (e)(3) of this section; or</P>
                        <P>(iii) A determination is made that the health IT developer is noncompliant with a Condition or Maintenance of Certification requirement under subpart D of this part or for the following circumstances when ONC exercises direct review under paragraph (a)(2)(iii) of this section:</P>
                        <P>(A) The health IT developer fails to timely respond to any communication from ONC, including, but not limited to:</P>
                        <P>
                            (
                            <E T="03">1</E>
                            ) Fact-finding;
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) A notice of potential non-conformity within the timeframe established in accordance with paragraph (b)(1)(ii)(A)(3) of this section; or
                        </P>
                        <P>
                            (
                            <E T="03">3</E>
                            ) A notice of non-conformity within the timeframe established in accordance with paragraph (b)(2)(ii)(A)(3) of this section.
                        </P>
                        <P>(B) The information or access provided by the health IT developer in response to any ONC communication, including, but not limited to: Fact-finding, a notice of potential non-conformity, or a notice of non-conformity is insufficient or incomplete;</P>
                        <P>(C) The health IT developer fails to cooperate with ONC and/or a third party acting on behalf of ONC;</P>
                        <P>(D) The health IT developer fails to timely submit in writing a proposed corrective action plan;</P>
                        <P>(E) The health IT developer fails to timely submit a corrective action plan that adequately addresses the elements required by ONC as described in paragraph (c) of this section;</P>
                        <P>(F) The health IT developer does not fulfill its obligations under the corrective action plan developed in accordance with paragraph (c) of this section; or</P>
                        <P>(G) The National Coordinator concludes that the non-conformity(ies) cannot be cured.</P>
                        <P>(iv) The National Coordinator determines, based on the notification made by an ONC-ACB under 45 CFR 170.556(d)(7) and the record sent to ONC pursuant to 45 CFR 170.523(x), that the developer did not fulfill its obligations under a corrective action plan.</P>
                        <P>(2) When the National Coordinator decides to terminate a certification, ONC will notify the health IT developer of its determination through a notice of termination.</P>
                        <P>(i) The notice of termination will include, but may not be limited to:</P>
                        <P>(A) An explanation for the termination;</P>
                        <P>(B) Information supporting the determination;</P>
                        <P>(C) The consequences of termination for the health IT developer and the Health IT Module under the ONC Health IT Certification Program; and</P>
                        <P>(D) Instructions for appealing the termination.</P>
                        <P>(ii) A termination of a certification will become effective after the following applicable occurrence:</P>
                        <P>(A) The expiration of the 10-day period for filing a statement of intent to appeal in paragraph (g)(3)(i) of this section if the health IT developer does not file a statement of intent to appeal.</P>
                        <P>(B) The expiration of the 30-day period for filing an appeal in paragraph (g)(3)(ii) of this section if the health IT developer files a statement of intent to appeal, but does not file a timely appeal.</P>
                        <P>(C) A final determination to terminate the certification per paragraph (g)(7) of this section if a health IT developer files an appeal.</P>
                        <P>(3) The health IT developer must notify all potentially affected customers of the identified non-conformity(ies) and termination of certification in a timely manner.</P>
                        <P>(4) The National Coordinator may rescind a termination determination before the termination becomes effective if the National Coordinator determines that termination is no longer appropriate.</P>
                        <P>(5) The Secretary may, at the Secretary's discretion, review a termination determination made by the National Coordinator pursuant to paragraph (f)(1) of this section before the termination becomes effective as specified in paragraph (f)(2)(ii) of this section. If the Secretary directs the National Coordinator to rescind the termination, ONC may:</P>
                        <P>(i) Resume all or part of its review of certified health IT or a health IT developer's actions or practices under this section unless the Secretary specifically directs otherwise; or</P>
                        <P>(ii) End all or part of its review of certified health IT or a health IT developer's actions or practices under this section unless the Secretary specifically directs otherwise.</P>
                        <P>
                            (g) 
                            <E T="03">Appeal</E>
                            —(1) 
                            <E T="03">Basis for appeal.</E>
                             A health IT developer may appeal a determination to suspend or terminate a certification issued to a Health IT Module under this section, a determination to issue a certification ban under § 170.581(a)(2), or both, if the health IT developer asserts:
                        </P>
                        <P>(i) The determination is based on an incorrect application of ONC Health IT Certification Program requirements for a:</P>
                        <P>(A) Suspension;</P>
                        <P>(B) Termination; or</P>
                        <P>(C) Certification ban under § 170.581(a)(2).</P>
                        <P>(ii) The National Coordinator's determination was not sufficiently supported by the information included in the notice(s) issued under paragraph (d)(2) or (f)(2) of this section, or both.</P>
                        <P>
                            (2) 
                            <E T="03">Method and place for filing an appeal.</E>
                             A statement of intent to appeal followed by a request for appeal must be submitted to ONC in writing by an authorized representative of the health IT developer subject to the determination being appealed. The statement of intent to appeal and request for appeal must be filed in accordance with the requirements specified in the notice of:
                        </P>
                        <P>(i) Termination;</P>
                        <P>(ii) Suspension; or</P>
                        <P>(iii) Certification ban under § 170.581(a)(2).</P>
                        <P>
                            (3) 
                            <E T="03">Time for filing a request for appeal.</E>
                             (i) A statement of intent to appeal must be filed within 10 days of a health IT developer's receipt of the notice of:
                        </P>
                        <P>(A) Suspension;</P>
                        <P>(B) Termination; or</P>
                        <P>(C) Certification ban under § 170.581(a)(2).</P>
                        <P>(ii) An appeal, including all supporting documentation, must be filed within 30 days of the filing of the intent to appeal.</P>
                        <P>
                            (4) 
                            <E T="03">Effect of appeal.</E>
                             (i) A request for appeal stays the termination of a certification issued to a Health IT Module, but the Health IT Module is prohibited from being marketed, licensed, or sold as “certified” during the stay.
                        </P>
                        <P>(ii) A request for appeal does not stay the suspension of a Health IT Module.</P>
                        <P>(iii) A request for appeal stays a certification ban issued under § 170.581(a)(2).</P>
                        <P>
                            (5) 
                            <E T="03">Assignment of a hearing officer.</E>
                             The National Coordinator will arrange for assignment of the case to a hearing officer to adjudicate the appeal on his or her behalf.
                        </P>
                        <P>
                            (i) The hearing officer may not review an appeal in which he or she participated in the initial suspension, termination, or certification ban determination or has a conflict of interest in the pending matter.
                            <PRTPAGE P="63802"/>
                        </P>
                        <P>(ii) The hearing officer must be trained in a nationally recognized ethics code that articulates nationally recognized standards of conduct for hearing officers/officials.</P>
                        <P>(iii) The hearing officer must be an officer properly appointed by the Secretary of Health and Human Services.</P>
                        <P>
                            (6) 
                            <E T="03">Adjudication.</E>
                             (i) The hearing officer may make a determination based on:
                        </P>
                        <P>(A) The written record, which includes the:</P>
                        <P>
                            (
                            <E T="03">1</E>
                            ) National Coordinator determination and supporting documentation;
                        </P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) Information provided by the health IT developer with the appeal filed in accordance with paragraphs (g)(1) through (3) of this section; and
                        </P>
                        <P>
                            (
                            <E T="03">3</E>
                            ) Information ONC provides in accordance with paragraph (g)(6)(v) of this section; or(B) All the information provided in accordance with paragraph (g)(6)(i)(A) and any additional information from a hearing conducted in-person, via telephone, or otherwise.
                        </P>
                        <P>(ii) The hearing officer will have the discretion to conduct a hearing if he/she:</P>
                        <P>(A) Requires clarification by either party regarding the written record under paragraph (g)(6)(i)(A) of this section;</P>
                        <P>(B) Requires either party to answer questions regarding the written record under paragraph (g)(6)(i)(A) of this section; or</P>
                        <P>(C) Otherwise determines a hearing is necessary.</P>
                        <P>(iii) The hearing officer will neither receive witness testimony nor accept any new information beyond what was provided in accordance with paragraph (g)(6)(i) of this section.</P>
                        <P>(iv) The default process will be a determination in accordance with paragraph (g)(6)(i)(A) of this section.</P>
                        <P>(v) ONC will have an opportunity to provide the hearing officer with a written statement and supporting documentation on its behalf that clarifies, as necessary, the National Coordinator's determination to suspend or terminate the certification or issue a certification ban.</P>
                        <P>
                            (7) 
                            <E T="03">Determination by the hearing officer.</E>
                             (i) The hearing officer will issue a written determination to the health IT developer within a timeframe agreed to by the health IT developer and ONC and approved by the hearing officer, unless the National Coordinator cancels the suspension or rescinds the termination determination.
                        </P>
                        <P>(ii) The determination on appeal, as issued by the hearing officer, becomes final thirty (30) calendar days after the hearing officer sent notice of the determination to the health IT developer unless the Secretary, at the Secretary's sole discretion, chooses within that time to review the determination and decides to revise or rescind the determination.</P>
                    </SECTION>
                    <AMDPAR>25. Amend § 170.581 by:</AMDPAR>
                    <AMDPAR>a. Revising paragraphs (a)(1)(i) and (a)(2);</AMDPAR>
                    <AMDPAR>b. Adding paragraph (a)(3); and</AMDPAR>
                    <AMDPAR>c. Revising paragraphs (b) introductory text and (d)(4).</AMDPAR>
                    <P>The revisions and addition read as follows:</P>
                    <SECTION>
                        <SECTNO>§ 170.581</SECTNO>
                        <SUBJECT>Certification Ban</SUBJECT>
                        <P>(a) * * *</P>
                        <P>(1) * * *</P>
                        <P>(i) Terminated by ONC under § 170.580(f);</P>
                        <STARS/>
                        <P>(2) The National Coordinator determines a certification ban is appropriate per ONC Direct Review under § 170.580(a)(2)(iii) or based on ONC's review of the record sent to ONC pursuant to § 170.523(x) and confirmation of a determination made by an ONC-ACB under § 170.556(d)(7).</P>
                        <P>(3) A certification ban determination made by the National Coordinator under paragraph (a)(2) of this section is subject to review by the Secretary, at the Secretary's sole discretion, at any time prior to its effective date.</P>
                        <P>
                            (b) 
                            <E T="03">Notice of certification ban.</E>
                             When the National Coordinator decides to issue a certification ban to a health IT developer, ONC will notify the health IT developer of the certification ban through a notice of certification ban. The notice of certification ban will include, but may not be limited to:
                        </P>
                        <STARS/>
                        <P>(d) * * *</P>
                        <P>(4) Upon review of ONC's assessment of the developer's demonstration under paragraph (d)(2) of this section and recommendation, the National Coordinator determines the health IT developer's demonstration under paragraph (d)(2) satisfactory and grants reinstatement into the ONC Health IT Certification Program.</P>
                    </SECTION>
                    <PART>
                        <HD SOURCE="HED">PART 171—INFORMATION BLOCKING</HD>
                    </PART>
                    <AMDPAR>26. 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>
                    <AMDPAR>27. Amend § 171.101 by adding paragraph (c) to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 171.101</SECTNO>
                        <SUBJECT>Applicability</SUBJECT>
                        <STARS/>
                        <P>(c) If any provision of this part is held to be invalid or unenforceable facially, or as applied to any person, plaintiff, or circumstance, it shall be construed to give maximum effect to the provision permitted by law, unless such holding shall be one of utter invalidity or unenforceability, in which case the provision shall be severable from this part and shall not affect the remainder thereof or the application of the provision to other persons not similarly situated or to other dissimilar circumstances.</P>
                    </SECTION>
                    <AMDPAR>28. Amend § 171.102 by adding definitions for “Business day or business days”, “Health information technology”, and “Reproductive health care” in alphabetical order and by revising the definition of “Health care provider” to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 171.102</SECTNO>
                        <SUBJECT>Definitions.</SUBJECT>
                        <STARS/>
                        <P>
                            <E T="03">Business day</E>
                             or 
                            <E T="03">business days</E>
                             is defined as it is in § 170.102.
                        </P>
                        <STARS/>
                        <P>
                            <E T="03">Health care provider</E>
                             has the same meaning as “health care provider” in 42 U.S.C. 300jj(3), within which for purposes of this definition:
                        </P>
                        <P>
                            (1) 
                            <E T="03">Laboratory</E>
                             has the same meaning as “laboratory” in 42 U.S.C. 300jj(10); and
                        </P>
                        <P>
                            (2) 
                            <E T="03">Pharmacist</E>
                             has the same meaning as “pharmacist” in 42 U.S.C. 300jj(12).
                        </P>
                        <STARS/>
                        <P>
                            <E T="03">Health information technology</E>
                             or 
                            <E T="03">health IT</E>
                             has the same meaning as “health information technology” in 42 U.S.C. 300jj(5).
                        </P>
                        <P>
                            <E T="03">Reproductive health care</E>
                             is defined as it is in 45 CFR 160.103.
                        </P>
                        <STARS/>
                    </SECTION>
                    <AMDPAR>29. Add § 171.104 to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 171.104</SECTNO>
                        <SUBJECT>Interferences.</SUBJECT>
                        <P>(a) The following constitute practices that are likely to interfere with the access, exchange, or use of electronic health information (EHI) for purposes of § 171.103:</P>
                        <P>
                            (1) 
                            <E T="03">Delay on new access.</E>
                             Delaying patient access to new EHI, such as diagnostic testing results, so clinicians or other actor representatives can review the EHI.
                        </P>
                        <P>
                            (2) 
                            <E T="03">Portal access.</E>
                             Delaying patient access to EHI in a portal when the actor has the EHI and the actor's system has the technical capability to support automated access, exchange, or use of the EHI via the portal.
                        </P>
                        <P>
                            (3) 
                            <E T="03">API access.</E>
                             Delaying the access, exchange, or use of EHI to or by a third-party app designated and authorized by the patient, when there is a deployed application programming interface (API) able to support the access, exchange, or use of the EHI.
                        </P>
                        <P>
                            (4) 
                            <E T="03">Non-standard implementation.</E>
                             Implementing health information 
                            <PRTPAGE P="63803"/>
                            technology in ways that are likely to restrict access, exchange, or use of EHI with respect to exporting electronic health information, including, but not limited to, exports for transitioning between health IT systems.
                        </P>
                        <P>
                            (5) 
                            <E T="03">Contract provisions.</E>
                             Negotiating or enforcing a contract provision that restricts or limits otherwise lawful access, exchange, or use of EHI.
                        </P>
                        <P>
                            (6) 
                            <E T="03">Non-compete provisions in agreements.</E>
                             Negotiating or enforcing a clause in any agreement that:
                        </P>
                        <P>(i) Prevents or restricts an employee (other than the actor's employees), a contractor, or a contractor's employee.</P>
                        <P>(ii) Who accesses, exchanges, or uses the EHI in the actor's health IT.</P>
                        <P>(iii) From accessing, exchanging, or using EHI in other health IT in order to design, develop, or upgrade such other health IT.</P>
                        <P>
                            (7) 
                            <E T="03">Manner or content requested.</E>
                             Improperly encouraging or inducing requestors to limit the scope, manner, or timing of EHI requested for access, exchange, or use.
                        </P>
                        <P>
                            (8) 
                            <E T="03">Medical images.</E>
                             Requiring that the access, exchange, or use of any medical images (including, but not limited to, photograph, x-rays, and imaging scans) occur by exchanging physical copies or copies on physical media (such as thumb drive or DVD) when the actor and the requestor possess the technical capability to access, exchange, or use the images through fully electronic means.
                        </P>
                        <P>
                            (9) 
                            <E T="03">Omissions.</E>
                             The following omissions:
                        </P>
                        <P>(i) Not exchanging EHI under circumstances in which such exchange is lawful;</P>
                        <P>(ii) Not making EHI available for lawful use;</P>
                        <P>(iii) Not complying with another valid law enforceable against the actor that requires access, exchange or use of EHI;</P>
                        <P>(iv) A Certified API Developer (as defined in 45 CFR 170.404) failing to publish API discovery details as required by the maintenance of certification requirement in 45 CFR 170.404(b)(2);</P>
                        <P>(v) An API Information Source (as defined in 45 CFR 170.404) failing to disclose to the Certified API Developer the information necessary for the Certified API Developer to publish the API discovery details required by 45 CFR 170.404(b)(2).</P>
                        <P>(b) The acts and omissions that will constitute practices that are likely to interfere with the access, exchange, or use of electronic health information (EHI) for purposes of § 171.103 include acts and omissions beyond those listed in paragraph (a) of this section.</P>
                    </SECTION>
                    <AMDPAR>30. Amend § 171.202 by revising paragraphs (a)(2), (d), and (e) introductory text to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 171.202</SECTNO>
                        <SUBJECT>Privacy exception—When will an actor's practice of not fulfilling a request to access, exchange, or use electronic health information in order to protect an individual's privacy not be considered information blocking?</SUBJECT>
                        <STARS/>
                        <P>(a) * * *</P>
                        <P>
                            (2) The term 
                            <E T="03">individual</E>
                             as used in this section means one or more of the following—
                        </P>
                        <P>(i) An individual as defined by 45 CFR 160.103.</P>
                        <P>(ii) Any other natural person who is the subject of the electronic health information being accessed, exchanged, or used.</P>
                        <P>(iii) A person who legally acts on behalf of a person described in paragraph (a)(2)(i) of this section in making decisions related to health care as a personal representative, in accordance with 45 CFR 164.502(g).</P>
                        <P>(iv) A person who is a legal representative of and can make health care decisions on behalf of any person described in paragraph (a)(2)(i) or (ii) of this section.</P>
                        <P>(v) An executor, administrator, or other person having authority to act on behalf of a deceased person described in paragraph (a)(2)(i) or (ii) of this section or the individual's estate under State or other law.</P>
                        <STARS/>
                        <P>
                            (d) 
                            <E T="03">Sub-exception—interfering with individual access based on unreviewable grounds.</E>
                        </P>
                        <P>Regardless of whether the actor is otherwise required to comply with 45 CFR 164.524, the actor's practice must be implemented in circumstances consistent with 45 CFR 164.524(a)(2) and must meet the implementation specifications that apply under 45 CFR 164.524 to denial of access on unreviewable grounds.</P>
                        <P>
                            (e) 
                            <E T="03">Sub-exception—individual's request not to share EHI.</E>
                             An actor may elect not to provide access, exchange, or use of an individual's electronic health information if the following requirements are met—
                        </P>
                        <STARS/>
                    </SECTION>
                    <AMDPAR>31. Amend § 171.204 by revising paragraphs (a)(2) and (3) and (b) 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>
                        <P>(a) * * *</P>
                        <P>
                            (2) 
                            <E T="03">Segmentation.</E>
                             The actor cannot fulfill the request for access, exchange, or use of electronic health information because the actor cannot unambiguously segment the requested electronic health information from electronic health information that:
                        </P>
                        <P>(i) Is not permitted by applicable law to be made available; or</P>
                        <P>(ii) May be withheld in accordance with § 171.201, § 171.202, or § 171.206.</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 any of the following:
                        </P>
                        <P>(i) A covered entity as defined in 45 CFR 160.103 requesting such use from an actor that is its business associate as defined in 45 CFR 160.103.</P>
                        <P>(ii) A health care provider, as defined in § 171.102 and who is not a covered entity as defined in 45 CFR 160.103, requesting such use from an actor who engages in activities that would make the actor the health care provider's business associate if the health care provider were a covered entity.</P>
                        <STARS/>
                        <P>
                            (b) 
                            <E T="03">Responding to requests.</E>
                             The actor must respond to the requestor as specified below based on the condition in paragraph (a) of this section that applies to the actor's not fulfilling the particular requested access, exchange, or use of electronic health information:
                        </P>
                        <P>(1) If an actor does not fulfill a request for access, exchange, or use of electronic health information for reasons consistent with paragraph (a)(1), (2), or (3) of this section, the actor must, within ten business days of the actor receiving the request, inform the requestor in writing of the reason(s) that request is infeasible.</P>
                        <P>(2) If an actor does not fulfill a request for access, exchange, or use of electronic health information for reasons consistent with paragraph (a)(4) or (5) of this section, the actor must:</P>
                        <P>(i) Determine, without unnecessary delay and based on a reasonable assessment of the facts, that the requested access, exchange, or use cannot be provided in accordance with § 171.301 or is infeasible under the circumstances; and</P>
                        <P>(ii) Inform the requestor in writing of the reason(s) that request is infeasible within ten business days of the determination under paragraph (b)(2)(i) of this section.</P>
                    </SECTION>
                    <AMDPAR>32. Add § 171.206 to read as follows:</AMDPAR>
                    <SECTION>
                        <PRTPAGE P="63804"/>
                        <SECTNO>§ 171.206</SECTNO>
                        <SUBJECT>Protecting Care Access—When will an actor's practice that is likely to interfere with the access, exchange, or use of electronic health information in order to reduce potential exposure to legal action not be considered information blocking?</SUBJECT>
                        <P>An actor's practice that is implemented to reduce potential exposure to legal action will not be considered information blocking when the practice satisfies the condition in paragraph (a) of this section and also satisfies the requirements of at least one of the conditions in paragraph (b) or (c) of this section.</P>
                        <P>
                            (a) 
                            <E T="03">Threshold condition.</E>
                             To satisfy this condition, a practice must meet each of the following requirements:
                        </P>
                        <P>
                            (1) 
                            <E T="03">Belief.</E>
                             The practice is undertaken based on the actor's good faith belief that:
                        </P>
                        <P>(i) Persons seeking, obtaining, providing, or facilitating reproductive health care are at risk of being potentially exposed to legal action that could arise as a consequence of particular access, exchange, or use of specific electronic health information; and</P>
                        <P>(ii) Specific practices likely to interfere with such access, exchange, or use of such electronic health information could reduce that risk.</P>
                        <P>
                            (2) 
                            <E T="03">Tailoring.</E>
                             The practice is no broader than necessary to reduce the risk of potential exposure to legal action that the actor in good faith believes could arise from the particular access, exchange, or use of the specific electronic health information.
                        </P>
                        <P>
                            (3) 
                            <E T="03">Implementation.</E>
                             The practice is implemented either consistent with an organizational policy that meets paragraph (a)(3)(i) of this section or pursuant to a case-by-case determination that meets paragraph (a)(3)(ii) of this section.
                        </P>
                        <P>(i) An organizational policy must:</P>
                        <P>(A) Be in writing;</P>
                        <P>(B) Be based on relevant clinical, technical, and other appropriate expertise;</P>
                        <P>(C) Identify the connection or relationship between the interference with particular access, exchange, or use of specific electronic health information and the risk of potential exposure to legal action that the actor believes the interference could reduce;</P>
                        <P>(D) Be implemented in a consistent and non-discriminatory manner; and</P>
                        <P>(E) Conform to the requirements in paragraphs (a)(1) and (2) of this section and to the requirements of at least one of the conditions in paragraph (b) or (c) of this section that are applicable to the prohibition of the access, exchange, or use of the electronic health information.</P>
                        <P>(ii) A case-by-case determination:</P>
                        <P>(A) Is made by the actor in the absence of an organizational policy applicable to the particular situation;</P>
                        <P>(B) Is based on facts and circumstances known to, or believed in good faith by, the actor at the time of the determination;</P>
                        <P>(C) Conforms to the conditions in paragraphs (a)(1) and (2) of this section; and</P>
                        <P>(D) Is documented either before or contemporaneous with engaging in any practice based on the determination. Documentation of the determination must identify the connection or relationship between the interference with particular access, exchange, or use of specific electronic health information and the risk of potential exposure to legal action.</P>
                        <P>
                            (b) 
                            <E T="03">Patient protection condition.</E>
                             When implemented for the purpose of reducing the patient's risk of potential exposure to legal action, the practice must:
                        </P>
                        <P>(1) Affect only the access, exchange, or use of specific electronic health information the actor in good faith believes could expose the patient to legal action because the electronic health information shows, or would carry a substantial risk of supporting a reasonable inference, that the patient:</P>
                        <P>(i) Obtained reproductive health care;</P>
                        <P>(ii) Inquired about or expressed an interest in seeking reproductive health care; or</P>
                        <P>(iii) Has any health condition(s) or history for which reproductive health care is often sought, obtained, or medically indicated.</P>
                        <P>(2) Be subject to nullification by an explicit request or directive from the patient that the access, exchange, or use of the specific electronic health information occur despite the risk(s) to the patient that the actor has identified.</P>
                        <P>(3) For purposes of paragraphs (b)(1) and (2) of this section, “patient” means the natural person who is the subject of the electronic health information or another natural person referenced in, or identifiable from, the EHI as a person who has sought or obtained reproductive health care.</P>
                        <P>
                            (c) 
                            <E T="03">Care access condition.</E>
                             When implemented for the purpose of reducing the risk of potential exposure to legal action for one or more licensed health care professionals, other health care providers, or other persons involved in providing or facilitating reproductive health care that is lawful under the circumstances in which such health care is provided, the practice must affect only access, exchange, or use of specific electronic health information that the actor believes could expose a care provider(s) and facilitator(s) to legal action because the information shows, or would carry a substantial risk of supporting a reasonable inference, that they provide or facilitate, or have provided or have facilitated, reproductive health care.
                        </P>
                        <P>
                            (d) 
                            <E T="03">Presumption.</E>
                             For purposes of determining whether an actor's practice meets paragraph (b)(1)(i) or (c) of this section, care provided by someone other than the actor is presumed to have been lawful unless the actor has actual knowledge that the care was not lawful under the circumstances in which such care is provided.
                        </P>
                        <P>
                            (e) 
                            <E T="03">Definition of legal action.</E>
                             As used in this section, legal action means any one or more of the following—
                        </P>
                        <P>(1) A criminal, civil, or administrative investigation into any person for the mere act of seeking, obtaining, providing, or facilitating reproductive health care;</P>
                        <P>(2) A civil or criminal action brought in a court to impose liability on any person for the mere act of seeking, obtaining, providing, or facilitating reproductive health care; or</P>
                        <P>(3) An administrative action or proceeding against any person for the mere act of seeking, obtaining, providing, or facilitating reproductive health care.</P>
                    </SECTION>
                    <AMDPAR>33. Add § 171.304 to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 171.304</SECTNO>
                        <SUBJECT>Requestor preferences exception—When will an actor's practice of tailoring the access, exchange, or use of electronic health information to a requestor's preference(s) not be considered information blocking?</SUBJECT>
                        <P>An actor's practice of tailoring the access, exchange, or use of electronic health information to a requestor's preference will not be considered information blocking when the practice meets the conditions in paragraphs (a) through (d) of this section.</P>
                        <P>
                            (a) 
                            <E T="03">Request.</E>
                             A requestor, without any improper encouragement or inducement by the actor, requests in writing that the actor:
                        </P>
                        <P>(1) Limit the scope of electronic health information made available for access, exchange, or use by the requestor;</P>
                        <P>(2) Delay provision of access, exchange, or use by the requestor of particular electronic health information until a condition specified by the requestor (such as passage of a particular event or completion of an action) has been met; or</P>
                        <P>(3) Delay provision of access, exchange, or use by the requestor of particular electronic health information for a specified period of time.</P>
                        <P>
                            (b) 
                            <E T="03">Implementation.</E>
                             The actor's practice must be:
                            <PRTPAGE P="63805"/>
                        </P>
                        <P>(1) Tailored to the specific request; and</P>
                        <P>(2) Implemented in a consistent and non-discriminatory manner.</P>
                        <P>
                            (c) 
                            <E T="03">Transparency.</E>
                             The actor must explain to the requestor in plain language, whether verbally or in writing, what tailoring the actor will implement and must notify, verbally or in writing, any requestor(s) of changes in the actor's ability to maintain tailoring. To satisfy this condition, the actor must, at a minimum:
                        </P>
                        <P>(1) Explain to the requestor what tailoring the actor will implement and how that will impact what EHI will be available to the requestor and when or under what conditions EHI will be available to the requestor;</P>
                        <P>(2) Upon the actor experiencing any change in operational status, technical capabilities, or other circumstances affecting the actor's ability or willingness to maintain particular tailoring of electronic health information, the actor must make reasonable efforts to promptly notify each requestor for which the actor had implemented the affected tailoring; and</P>
                        <P>(3) Contemporaneously document in writing any explanation consistent with paragraph (c)(1) of this section or notice consistent with paragraph (c)(2) of this section that is not provided in writing to the requestor.</P>
                        <P>
                            (d) 
                            <E T="03">Reduction or removal.</E>
                             An actor must act on any subsequent request from the requestor who previously requested scope, condition, or timing tailoring of the requestor's EHI access, exchange, or use to reduce or remove restrictions as promptly as feasible.
                        </P>
                    </SECTION>
                    <AMDPAR>34. Revise § 171.401 to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 171.401</SECTNO>
                        <SUBJECT>Definitions.</SUBJECT>
                        <P>
                            <E T="03">Common Agreement</E>
                             has the meaning given to it in 45 CFR 172.102.
                        </P>
                        <P>
                            <E T="03">Framework Agreement</E>
                             has the meaning given to it in 45 CFR 172.102.
                        </P>
                        <P>
                            <E T="03">Participant</E>
                             has the meaning given to it in 45 CFR 172.102.
                        </P>
                        <P>
                            <E T="03">Qualified Health Information Network</E>
                             or 
                            <E T="03">QHIN</E>
                             has the meaning given to it in 45 CFR 172.102.
                        </P>
                        <P>
                            <E T="03">Subparticipant</E>
                             has the meaning given to it in 45 CFR 172.102.
                        </P>
                    </SECTION>
                    <AMDPAR>35. Add part 172 to read as follows:</AMDPAR>
                    <PART>
                        <HD SOURCE="HED">PART 172—TRUSTED EXCHANGE FRAMEWORK AND COMMON AGREEMENT</HD>
                        <CONTENTS>
                            <SUBPART>
                                <HD SOURCE="HED">Subpart A—General Provisions</HD>
                                <SECHD>Sec.</SECHD>
                                <SECTNO>172.100</SECTNO>
                                <SUBJECT>Basis, purpose, and scope.</SUBJECT>
                                <SECTNO>172.101</SECTNO>
                                <SUBJECT>Applicability.</SUBJECT>
                                <SECTNO>172.102</SECTNO>
                                <SUBJECT>Definitions.</SUBJECT>
                                <SECTNO>172.103</SECTNO>
                                <SUBJECT>Responsibilities ONC may delegate to the RCE.</SUBJECT>
                            </SUBPART>
                            <SUBPART>
                                <HD SOURCE="HED">Subpart B—Qualifications for Designation</HD>
                                <SECTNO>172.200</SECTNO>
                                <SUBJECT>Applicability.</SUBJECT>
                                <SECTNO>172.201</SECTNO>
                                <SUBJECT>QHIN Designation requirements.</SUBJECT>
                                <SECTNO>172.202</SECTNO>
                                <SUBJECT>QHINS that offer Individual Access Services.</SUBJECT>
                            </SUBPART>
                            <SUBPART>
                                <HD SOURCE="HED">Subpart C—QHIN Onboarding and Designation Processes</HD>
                                <SECTNO>172.300</SECTNO>
                                <SUBJECT>Applicability.</SUBJECT>
                                <SECTNO>172.301</SECTNO>
                                <SUBJECT>Submission of QHIN application.</SUBJECT>
                                <SECTNO>172.302</SECTNO>
                                <SUBJECT>Review of QHIN application.</SUBJECT>
                                <SECTNO>172.303</SECTNO>
                                <SUBJECT>QHIN approval and onboarding.</SUBJECT>
                                <SECTNO>172.304</SECTNO>
                                <SUBJECT>QHIN Designation.</SUBJECT>
                                <SECTNO>172.305</SECTNO>
                                <SUBJECT>Withdrawal of QHIN application.</SUBJECT>
                                <SECTNO>172.306</SECTNO>
                                <SUBJECT>Denial of QHIN application.</SUBJECT>
                                <SECTNO>172.307</SECTNO>
                                <SUBJECT>Re-application and renewed applications.</SUBJECT>
                            </SUBPART>
                            <SUBPART>
                                <HD SOURCE="HED">Subpart D—Suspension</HD>
                                <SECTNO>172.400</SECTNO>
                                <SUBJECT>Applicability.</SUBJECT>
                                <SECTNO>172.401</SECTNO>
                                <SUBJECT>QHIN suspensions.</SUBJECT>
                                <SECTNO>172.402</SECTNO>
                                <SUBJECT>Selective suspension of exchange between QHINs.</SUBJECT>
                            </SUBPART>
                            <SUBPART>
                                <HD SOURCE="HED">Subpart E—Termination</HD>
                                <SECTNO>172.500</SECTNO>
                                <SUBJECT>Applicability</SUBJECT>
                                <SECTNO>172.501</SECTNO>
                                <SUBJECT>QHIN self-termination.</SUBJECT>
                                <SECTNO>172.502</SECTNO>
                                <SUBJECT>QHIN termination.</SUBJECT>
                                <SECTNO>172.503</SECTNO>
                                <SUBJECT>Termination by mutual agreement.</SUBJECT>
                            </SUBPART>
                            <SUBPART>
                                <HD SOURCE="HED">Subpart F—Review of RCE Decisions</HD>
                                <SECTNO>172.600</SECTNO>
                                <SUBJECT>Applicability.</SUBJECT>
                                <SECTNO>172.601</SECTNO>
                                <SUBJECT>ONC review.</SUBJECT>
                                <SECTNO>172.602</SECTNO>
                                <SUBJECT>Basis for appeal by QHIN or applicant QHIN.</SUBJECT>
                                <SECTNO>172.603</SECTNO>
                                <SUBJECT>Method and timing for filing an appeal.</SUBJECT>
                                <SECTNO>172.604</SECTNO>
                                <SUBJECT>Effect of appeal on suspension and termination.</SUBJECT>
                                <SECTNO>172.605</SECTNO>
                                <SUBJECT>Assignment of a hearing officer.</SUBJECT>
                                <SECTNO>172.606</SECTNO>
                                <SUBJECT>Adjudication.</SUBJECT>
                                <SECTNO>172.607</SECTNO>
                                <SUBJECT>Determination by the hearing officer.</SUBJECT>
                            </SUBPART>
                            <SUBPART>
                                <HD SOURCE="HED">Subpart G—QHIN Attestation for the Adoption of the Trusted Exchange Framework and Common Agreement</HD>
                                <SECTNO>172.700</SECTNO>
                                <SUBJECT>Applicability.</SUBJECT>
                                <SECTNO>172.701</SECTNO>
                                <SUBJECT>Attestation submission and acceptance.</SUBJECT>
                                <SECTNO>172.702</SECTNO>
                                <SUBJECT>QHIN directory.</SUBJECT>
                            </SUBPART>
                        </CONTENTS>
                        <AUTH>
                            <HD SOURCE="HED">Authority:</HD>
                            <P> 42 U.S.C. 300jj-11; 5 U.S.C. 552.</P>
                        </AUTH>
                        <SUBPART>
                            <HD SOURCE="HED">Subpart A—General Provisions</HD>
                            <SECTION>
                                <SECTNO>§ 172.100</SECTNO>
                                <SUBJECT>Basis, purpose, and scope.</SUBJECT>
                                <P>
                                    (a) 
                                    <E T="03">Basis and authority.</E>
                                     The provisions of this part implement section 3001(c)(9) of the Public Health Service Act.
                                </P>
                                <P>
                                    (b) 
                                    <E T="03">Purpose.</E>
                                     The purpose of this part is to:
                                </P>
                                <P>(1) Ensure full network-to-network exchange of health information; and</P>
                                <P>
                                    (2) Establish a voluntary process for a Qualified Health Information Network
                                    <SU>TM</SU>
                                     (QHIN
                                    <SU>TM</SU>
                                    ) to attest to adoption of the Trusted Exchange Framework and Common Agreement
                                    <SU>TM</SU>
                                     (TEFCA
                                    <SU>TM</SU>
                                    ).
                                </P>
                                <P>
                                    (c) 
                                    <E T="03">Scope.</E>
                                     This part addresses:
                                </P>
                                <P>(1) Minimum qualifications needed for a health information network to be Designated as a QHIN capable of trusted exchange under TEFCA.</P>
                                <P>(2) Procedures governing QHIN Onboarding and Designation, suspension, termination, and further administrative review.</P>
                                <P>(3) Attestation submission requirements for a QHIN to attest to its adoption of TEFCA.</P>
                                <P>(4) ONC attestation acceptance and removal processes for publication of attesting QHINs in the QHIN Directory.</P>
                            </SECTION>
                            <SECTION>
                                <SECTNO>§ 172.101</SECTNO>
                                <SUBJECT>Applicability.</SUBJECT>
                                <P>(a) This part applies to Applicant QHINS, QHINs, terminated QHINs, and the Recognized Coordinating Entity.</P>
                                <P>(b) If any provision of this part is held to be invalid or unenforceable facially, or as applied to any person, plaintiff, or circumstance, it shall be construed to give maximum effect to the provision permitted by law, unless such holding shall be one of utter invalidity or unenforceability, in which case the provision shall be severable from this part and shall not affect the remainder thereof or the application of the provision to other persons not similarly situated or to other dissimilar circumstances.</P>
                            </SECTION>
                            <SECTION>
                                <SECTNO>§ 172.102</SECTNO>
                                <SUBJECT>Definitions.</SUBJECT>
                                <P>For purposes of this part, the following definitions apply:</P>
                                <P>
                                    <E T="03">Applicable Law</E>
                                     means all Federal, State, local, or Tribal laws and regulations then in effect and applicable to the subject matter herein. For the avoidance of doubt, Federal agencies are subject only to Federal law.
                                </P>
                                <P>
                                    <E T="03">Applicant QHIN</E>
                                     means any organization with a pending QHIN application before the Office of the National Coordinator for Health Information Technology (ONC).
                                </P>
                                <P>
                                    <E T="03">Business Associate Agreement (BAA)</E>
                                     means a contract, agreement, or other arrangement that satisfies the implementation specifications described within 45 CFR parts 160 and 164 and subparts A, C, and E, as applicable.
                                </P>
                                <P>
                                    <E T="03">Business day</E>
                                     or 
                                    <E T="03">business days</E>
                                     has the meaning assigned to it in 45 CFR 170.102.
                                </P>
                                <P>
                                    <E T="03">Common Agreement</E>
                                     means the most recent version of the agreement referenced in section 3001(c)(9) of the Public Service Health Act as published in the 
                                    <E T="04">Federal Register</E>
                                    .
                                </P>
                                <P>
                                    <E T="03">Confidential Information</E>
                                     means any information that is designated as Confidential Information by the person or entity that discloses it, or that a reasonable person would understand to be of a confidential nature and is disclosed to another person or entity pursuant to TEFCA Exchange. For the avoidance of doubt, “Confidential 
                                    <PRTPAGE P="63806"/>
                                    Information” does not include electronic protected health information (ePHI). Notwithstanding any label to the contrary, “Confidential Information” does not include any information that:
                                </P>
                                <P>(1) Is or becomes known publicly through no fault of the Recipient; or</P>
                                <P>(2) Is learned by the recipient from a third party that the recipient reasonably believes is entitled to disclose it without restriction; or</P>
                                <P>(3) Is already known to the recipient before receipt from the discloser, as shown by the Recipient's written records; or</P>
                                <P>(4) Is independently developed by recipient without the use of or reference to the discloser's Confidential Information, as shown by the recipient's written records, and was not subject to confidentiality restrictions prior to receipt of such information from the discloser; or</P>
                                <P>(5) Must be disclosed under operation of law, provided that, to the extent permitted by Applicable Law, the recipient gives the discloser reasonable notice to allow the discloser to object to such redisclosure, and such redisclosure is made to the minimum extent necessary to comply with Applicable Law.</P>
                                <P>
                                    <E T="03">Connectivity Services</E>
                                     means the technical services provided by a QHIN, Participant, or Subparticipant to its Participants and Subparticipants that facilitate TEFCA Exchange and are consistent with the technical requirements of the TEFCA framework.
                                </P>
                                <P>
                                    <E T="03">Covered Entity</E>
                                     has the meaning assigned to such term at 45 CFR 160.103.
                                </P>
                                <P>
                                    <E T="03">Designated Network</E>
                                     means the Health Information Network that a QHIN uses to offer and provide Designated Network Services.
                                </P>
                                <P>
                                    <E T="03">Designated Network Services</E>
                                     means the Connectivity Services and/or Governance Services.
                                </P>
                                <P>
                                    <E T="03">Designation (including its correlative meanings “Designate,” “Designated,”</E>
                                     and 
                                    <E T="03">“Designating”)</E>
                                     means the written determination that an Applicant QHIN has satisfied all requirements and is now a QHIN.
                                </P>
                                <P>
                                    <E T="03">Disclosure (including its correlative meanings “Disclose,” “Disclosed,”</E>
                                     and 
                                    <E T="03">“Disclosing”)</E>
                                     means the release, transfer, provision of access to, or divulging in any manner of TEFCA Information (TI) outside the entity holding the information.
                                </P>
                                <P>
                                    <E T="03">Electronic Protected Health Information (ePHI)</E>
                                     has the meaning assigned to such term at 45 CFR 160.103.
                                </P>
                                <P>
                                    <E T="03">Exchange Purpose(s)</E>
                                     or 
                                    <E T="03">XP(s)</E>
                                     means the reason for a transmission, Query, Use, Disclosure, or Response transacted through TEFCA Exchange as a step in the transaction. Types of Exchange Purposes include, but are not limited to, treatment, payment, health care operations, Individual Access Services, public health, and government benefits determination.
                                </P>
                                <P>
                                    <E T="03">Exchange Purpose Code</E>
                                     or 
                                    <E T="03">XP Code</E>
                                     means a code that identifies the Exchange Purpose being used for TEFCA Exchange.
                                </P>
                                <P>
                                    <E T="03">Foreign Control</E>
                                     means a non-U.S. Person(s) or non-U.S. Entity(ies) having the direct or indirect power, whether or not exercised, to direct or decide matters materially affecting the Applicant's ability to function as a QHIN in a manner that presents a national security risk.
                                </P>
                                <P>
                                    <E T="03">Framework Agreement(s)</E>
                                     means with respect to QHINs, the Common Agreement; and with respect to a Participant or Subparticipant, the Participant/Subparticipant Terms of Participation (ToP).
                                </P>
                                <P>
                                    <E T="03">Governance Services</E>
                                     means the governance functions described in applicable SOP(s), which are performed by a QHIN's Designated Network Governance Body for its Participants and Subparticipants to facilitate TEFCA Exchange in compliance with the then-applicable requirements of the Framework Agreements.
                                </P>
                                <P>
                                    <E T="03">Health information network</E>
                                     or 
                                    <E T="03">HIN</E>
                                     has the meaning assigned to it in 45 CFR 171.102.
                                </P>
                                <P>
                                    <E T="03">Individual</E>
                                     has the meaning assigned to such term at 45 CFR 171.202(a)(2).
                                </P>
                                <P>
                                    <E T="03">HIPAA</E>
                                     means the Health Insurance Portability and Accountability Act of 1996.
                                </P>
                                <P>
                                    <E T="03">HIPAA Rules</E>
                                     means the regulations set forth at 45 CFR parts 160, 162, and 164.
                                </P>
                                <P>
                                    <E T="03">HIPAA Privacy Rule</E>
                                     means the regulations set forth at 45 CFR parts 160 and 164 and subparts A and E.
                                </P>
                                <P>
                                    <E T="03">HIPAA Security Rule</E>
                                     means the regulations set forth at 45 CFR parts 160 and 164 and subparts A and C.
                                </P>
                                <P>
                                    <E T="03">Individual Access Services (IAS)</E>
                                     means 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.
                                </P>
                                <P>
                                    <E T="03">Individually Identifiable Information</E>
                                     refers to information that identifies an Individual or with respect to which there is a reasonable basis to believe that the information could be used to identify an Individual.
                                </P>
                                <P>
                                    <E T="03">Node</E>
                                     means a technical system that is controlled directly or indirectly by a QHIN, Participant, or Subparticipant and that is listed in the RCE Directory Service.
                                </P>
                                <P>
                                    <E T="03">Non-U.S. Entity</E>
                                     means any Entity that is not a U.S. Entity.
                                </P>
                                <P>
                                    <E T="03">Non-U.S. Person</E>
                                     means any individual who is not a U.S. Qualified Person.
                                </P>
                                <P>
                                    <E T="03">Onboarding</E>
                                     means the process a prospective QHIN must undergo to become a QHIN and become operational in the production environment.
                                </P>
                                <P>
                                    <E T="03">Organized Health Care Arrangement</E>
                                     has the meaning assigned to such term at 45 CFR 160.103.
                                </P>
                                <P>
                                    <E T="03">Participant</E>
                                     means a U.S. Entity that has entered into the Participant/Subparticipant Terms of Participation in a legally binding contract with a QHIN to use the QHIN's Designated Network Services to participate in TEFCA Exchange in compliance with the Participant/Subparticipant Terms of Participation.
                                </P>
                                <P>
                                    <E T="03">Participant/Subparticipant Terms of Participation (ToP)</E>
                                     means the requirements to which QHINs must contractually obligate their Participants to agree; to which QHINs must contractually obligate their Participants to contractually obligate their Subparticipants and Subparticipants of the Subparticipants to agree, in order to participate in TEFCA Exchange including the QHIN Technical Framework (QTF), all applicable Standard Operating Procedures (SOPs), and all other attachments, exhibits, and artifacts incorporated therein by reference.
                                </P>
                                <P>
                                    <E T="03">Qualified Health Information Network</E>
                                    <SU>TM</SU>
                                     or 
                                    <E T="03">QHIN</E>
                                    <SU>TM</SU>
                                     means a Health Information Network that has been so Designated.
                                </P>
                                <P>
                                    <E T="03">Query(s) (including its correlative uses/tenses “Queried”</E>
                                     and 
                                    <E T="03">“Querying”)</E>
                                     means the act of asking for information through TEFCA Exchange.
                                </P>
                                <P>
                                    <E T="03">Recognized Coordinating Entity</E>
                                    ® or 
                                    <E T="03">RCE</E>
                                    <SU>TM</SU>
                                     means ONC's contractor that administers the implementation of TEFCA.
                                </P>
                                <P>
                                    <E T="03">Required Information</E>
                                     means the Electronic Health Information, as defined in 45 CFR 171.102, that is:
                                </P>
                                <P>(1) Maintained in a Responding Node by any QHIN, Participant, or Subparticipant prior to or during the term of the applicable Framework Agreement; and</P>
                                <P>(2) Relevant for a required XP Code.</P>
                                <P>
                                    <E T="03">Response(s) (including its correlative uses/tenses “Responds,” “Responded”</E>
                                     and 
                                    <E T="03">“Responding”)</E>
                                     means the act of providing the information that is the subject of a Query or otherwise 
                                    <PRTPAGE P="63807"/>
                                    transmitting a message in response to a Query through TEFCA Exchange.
                                </P>
                                <P>
                                    <E T="03">Subparticipant</E>
                                     means a U.S. Entity that has entered into the Participant/Subparticipant Terms of Participation in a legally binding contract with a Participant or another Subparticipant to use the Participant's or Subparticipant's Connectivity Services to participate in TEFCA Exchange in compliance with the Participant/Subparticipant Terms of Participation.
                                </P>
                                <P>
                                    <E T="03">TEFCA Dispute Resolution Process</E>
                                     means an informal, non-binding process under TEFCA through which QHINs can meet, confer, and seek to amicably resolve disputes.
                                </P>
                                <P>
                                    <E T="03">TEFCA Exchange</E>
                                     means the transaction of information between Nodes using an XP Code.
                                </P>
                                <P>
                                    <E T="03">TEFCA Information or TI</E>
                                     means any information that is transacted through TEFCA Exchange except to the extent that such information is received by a QHIN, Participant, or Subparticipant that is a Covered Entity, Business Associate, or non-HIPAA entity that is exempt from compliance with the Privacy section of the applicable Framework Agreement and is incorporated into such recipient's system of record, at which point the information is no longer TEFCA Information with respect to such recipient and is governed by the HIPAA Rules and other Applicable Law.
                                </P>
                                <P>
                                    <E T="03">TEFCA Security Incident</E>
                                     means:
                                </P>
                                <P>(1) An unauthorized acquisition, access, Disclosure, or Use of unencrypted TEFCA Information using TEFCA Exchange, except any of the following:</P>
                                <P>(i) Any unintentional acquisition, access, Use, or Disclosure of TEFCA Information by a Workforce Member or person acting under the authority of a QHIN, Participant, or Subparticipant, if such acquisition, access, Use, or Disclosure:</P>
                                <P>(A) Was made in good faith;</P>
                                <P>(B) Was made by a person acting within their scope of authority;</P>
                                <P>(C) Was made to another Workforce Member or person acting under the authority of any QHIN, Participant, or Subparticipant; and</P>
                                <P>(D) Does not result in further acquisition, access, Use, or Disclosure in a manner not permitted under Applicable Law and the Framework Agreements.</P>
                                <P>(ii) A Disclosure of TI where a QHIN, Participant, or Subparticipant has a good faith belief that an unauthorized person to whom the Disclosure was made would not reasonably have been able to retain such information.</P>
                                <P>(iii) A Disclosure of TI that has been de-identified in accordance with the standard at 45 CFR 164.514.</P>
                                <P>(2) Other security events that adversely affect a QHIN's, Participant's, or Subparticipant's participation in TEFCA Exchange.</P>
                                <P>
                                    <E T="03">Threat Condition</E>
                                     means:
                                </P>
                                <P>(1) A breach of a material provision of a Framework Agreement that has not been cured within fifteen (15) calendar days of receiving notice of the material breach (or such other period of time to which the contracting parties have agreed), which written notice shall include such specific information about the breach that is available at the time of the notice; or</P>
                                <P>(2) A TEFCA Security Incident; or</P>
                                <P>(3) An event that ONC (or an RCE), a QHIN, its Participant, or their Subparticipant has reason to believe will disrupt normal TEFCA Exchange, either:</P>
                                <P>(i) Due to actual compromise of, or the need to mitigate demonstrated vulnerabilities in, systems or data of the QHIN, Participant, or Subparticipant, as applicable; or</P>
                                <P>(ii) Through replication in the systems, networks, applications, or data of another QHIN, Participant, or Subparticipant; or</P>
                                <P>(4) Any event that could pose a risk to the interests of national security as directed by an agency of the United States government.</P>
                                <P>
                                    <E T="03">Trusted Exchange Framework</E>
                                     means the most recent version of the framework referenced in section 3001(c)(9) of the Public Service Health Act published in the 
                                    <E T="04">Federal Register</E>
                                    .
                                </P>
                                <P>
                                    <E T="03">U.S. Entity/Entities</E>
                                     means any corporation, limited liability company, partnership, or other legal entity that meets all of the following requirements:
                                </P>
                                <P>(1) The entity is organized under the laws of a State or commonwealth of the United States or the Federal law of the United States and is subject to the jurisdiction of the United States and the State or commonwealth under which it was formed;</P>
                                <P>(2) The entity's principal place of business, as determined under Federal common law, is in the United States; and</P>
                                <P>
                                    (3) None of the entity's directors, officers, or executives, and none of the owners with a five percent (5%) or greater interest in the entity, are listed on the 
                                    <E T="03">Specially Designated Nationals and Blocked Persons List</E>
                                     published by the United States Department of the Treasury's Office of Foreign Asset Control or on the United States Department of Health and Human Services, Office of Inspector General's List of Excluded Individuals/Entities.
                                </P>
                                <P>
                                    <E T="03">U.S. Qualified Person</E>
                                     means those individuals who are U.S. nationals and citizens at birth as defined in 8 U.S.C 1401, U.S. nationals but not citizens of the United States at birth as defined in 8 U.S.C. 1408, lawful permanent residents of the United States as defined in Immigration and Nationality Act, and non-immigrant aliens who are hired by a U.S. Entity as an employee in a specialty occupation pursuant to an H-1B Visa.
                                </P>
                                <P>
                                    <E T="03">Use(s) (including correlative uses/tenses, such as “Uses,” “Used,”</E>
                                     and 
                                    <E T="03">“Using”),</E>
                                     with respect to TI, means the sharing, employment, application, utilization, examination, or analysis of such information within an entity that maintains such information.
                                </P>
                            </SECTION>
                            <SECTION>
                                <SECTNO>§ 172.103</SECTNO>
                                <SUBJECT>Responsibilities ONC may delegate to the RCE.</SUBJECT>
                                <P>(a) ONC may delegate to the RCE the TEFCA implementation responsibilities specified in the following sections:</P>
                                <P>(1) Any section(s) of subpart C of this part;</P>
                                <P>(2) Any section(s) of subpart D of this part;</P>
                                <P>(3) Section 172.501; and</P>
                                <P>(4) Section 172.503.</P>
                                <P>(b) Any authority exercised by the RCE under this section is subject to review under subpart F of this part.</P>
                            </SECTION>
                        </SUBPART>
                        <SUBPART>
                            <HD SOURCE="HED">Subpart B—Qualifications for Designation</HD>
                            <SECTION>
                                <SECTNO>§ 172.200</SECTNO>
                                <SUBJECT>Applicability.</SUBJECT>
                                <P>This subpart establishes Designation qualifications.</P>
                                <P>
                                    (a) 
                                    <E T="03">Applicant QHIN.</E>
                                     An Applicant QHIN must meet all requirements in § 172.201 to be Designated. An Applicant QHIN that proposes to offer Individual Access Services must also meet all requirements in § 172.202 to be Designated.
                                </P>
                                <P>
                                    (b) 
                                    <E T="03">QHIN.</E>
                                     A QHIN must continue to meet all requirements in § 172.201 to maintain its Designation. A QHIN that offers Individual Access Services must also continue to meet all requirements in § 172.202 to maintain its Designation.
                                </P>
                                <P>
                                    (c) 
                                    <E T="03">Performance of TEFCA Exchange.</E>
                                     The Designation qualifications in §§ 172.201 and 172.202 describe certain requirements for Designation.
                                </P>
                            </SECTION>
                            <SECTION>
                                <SECTNO>§ 172.201</SECTNO>
                                <SUBJECT>QHIN Designation requirements.</SUBJECT>
                                <P>
                                    (a) 
                                    <E T="03">Ownership requirements.</E>
                                     An entity must:
                                </P>
                                <P>(1) be a U.S. Entity;</P>
                                <P>(2) Not be under Foreign Control.</P>
                                <P>
                                    (b) 
                                    <E T="03">Exchange requirements.</E>
                                     An entity must, beginning at the time of application, either directly or through the experience of its parent entity:
                                    <PRTPAGE P="63808"/>
                                </P>
                                <P>(1) Be capable of exchanging information among more than two unaffiliated organizations;</P>
                                <P>(2) Be capable of exchanging all Required Information;</P>
                                <P>(3) Be exchanging information for at least one Exchange Purpose authorized under TEFCA;</P>
                                <P>(4) Be capable of receiving and responding to transactions from other QHINs for all Exchange Purposes authorized under TEFCA;</P>
                                <P>(5) Be capable of initiating transactions for the Exchange Purposes authorized under TEFCA that such entity will permit its Participants and Subparticipants to use through TEFCA Exchange.</P>
                                <P>
                                    (c) 
                                    <E T="03">Designated Network Services requirements.</E>
                                     An entity must:
                                </P>
                                <P>(1) Maintain the organizational infrastructure and legal authority to operate and govern its Designated Network;</P>
                                <P>(2) Maintain adequate written policies and procedures to support meaningful TEFCA Exchange and fulfill all responsibilities of a QHIN in this Part;</P>
                                <P>(3) Maintain a Designated Network that can support a transaction volume that keeps pace with the demands of network users;</P>
                                <P>(4) Maintain the capacity to support secure technical connectivity and data exchange with other QHINs;</P>
                                <P>(5) Maintain an enforceable dispute resolution policy governing Participants in the Designated Network that permits Participants to reasonably, timely, and fairly adjudicate disputes that arise between each other, the QHIN, or other QHINs;</P>
                                <P>(6) Maintain an enforceable change management policy consistent with the responsibilities of a QHIN;</P>
                                <P>(7) Maintain a representative and participatory group or groups with the authority to approve processes for governing the Designated Network;</P>
                                <P>(8) Maintain privacy and security policies that permit the entity to support TEFCA Exchange;</P>
                                <P>(9) Maintain data breach response and management policies that support meaningful TEFCA Exchange; and</P>
                                <P>(10) Maintain adequate financial and personnel resources to support all its responsibilities as a QHIN, including sufficient financial reserves or insurance-based cybersecurity coverage, or a combination of both.</P>
                            </SECTION>
                            <SECTION>
                                <SECTNO>§ 172.202</SECTNO>
                                <SUBJECT>QHINs that offer Individual Access Services.</SUBJECT>
                                <P>The following requirements apply to QHINs that offer Individual Access Services:</P>
                                <P>(a) A QHIN must obtain express consent from any individual before providing Individual Access Services.</P>
                                <P>(b) A QHIN must make publicly available a privacy and security notice that meets minimum TEFCA standards.</P>
                                <P>(c) A QHIN, that is the IAS provider for an individual, must delete the individual's Individually Identifiable Information maintained by the QHIN upon request by the individual except as prohibited by Applicable Law or where such information is contained in audit logs.</P>
                                <P>(d) A QHIN must permit any individual to export in a computable format all of the individual's Individually Identifiable Information maintained by the QHIN as an Individual Access Services provider.</P>
                                <P>(e) All Individually Identifiable Information the QHIN maintains must satisfy the following criteria:</P>
                                <P>(1) All Individually Identifiable Information must be encrypted.</P>
                                <P>(2) Without unreasonable delay and in no case later than sixty (60) calendar days following discovery of the unauthorized acquisition, access, Disclosure, or Use of Individually Identifiable Information, the QHIN must notify in plain language each individual whose Individually Identifiable Information has been or is reasonably believed to have been affected by unauthorized acquisition, access, Disclosure, or Use involving the QHIN.</P>
                                <P>(3) A QHIN must have an agreement with a qualified, independent third-party credential service provider and must verify, through the credential service provider, the identities of individuals seeking Individual Access Services prior to the individuals' first use of such services and upon expiration of their credentials.</P>
                            </SECTION>
                        </SUBPART>
                        <SUBPART>
                            <HD SOURCE="HED">Subpart C—QHIN Onboarding and Designation Processes</HD>
                            <SECTION>
                                <SECTNO>§ 172.300</SECTNO>
                                <SUBJECT>Applicability.</SUBJECT>
                                <P>This subpart establishes, as to QHINs, the application, review, Onboarding, withdrawal, and redetermination processes for Designation.</P>
                            </SECTION>
                            <SECTION>
                                <SECTNO>§ 172.301</SECTNO>
                                <SUBJECT>Submission of QHIN application.</SUBJECT>
                                <P>An entity seeking to be Designated as a QHIN must submit all of the following information in a manner specified by ONC:</P>
                                <P>(a) Completed QHIN application, with supporting documentation, in a form specified by ONC; and</P>
                                <P>(b) A signed copy of the Common Agreement.</P>
                            </SECTION>
                            <SECTION>
                                <SECTNO>§ 172.302</SECTNO>
                                <SUBJECT>Review of QHIN application.</SUBJECT>
                                <P>(a) ONC (or an RCE) will review a QHIN application to determine if the Applicant QHIN has completed all parts of the application and provided the necessary supporting documentation. If the QHIN application is not complete, the applicant will be notified in writing of the missing information within thirty (30) calendar days of receipt of the application. This timeframe may be extended by providing written notice to the Applicant QHIN.</P>
                                <P>(b) Once the QHIN application is complete, ONC (or an RCE) will review the application to determine whether the Applicant QHIN satisfies the requirements for Designation set forth in § 172.201 and, if the Applicant QHIN proposes to provide IAS, the requirements set forth in § 172.202. ONC (or an RCE) will complete its review within sixty (60) calendar days of the Applicant QHIN being provided with written notice that its application is complete. This timeframe may be extended by providing written notice to the Applicant QHIN.</P>
                                <P>(c) Additional information may be requested from the Applicant QHIN while ONC (or an RCE) is reviewing the application. The timeframe for responding to the request and the manner to submit additional information will be provided to the applicant and may be extended on written notice to the Applicant QHIN.</P>
                                <P>(d) Failure to respond to a request within the proposed timeframe or in the manner specified is a basis for a QHIN Application to be deemed withdrawn, as set forth in § 172.305(c). In such situations, the Applicant QHIN will be provided with written notice that the application has been deemed withdrawn.</P>
                                <P>(e) If, following submission of the application, any information submitted by the Applicant QHIN becomes untrue or materially changes, the Applicant QHIN must notify ONC (or an RCE) in the manner specified by ONC (or an RCE) of such changes in writing within five (5) business days of the submitted material becoming untrue or materially changing.</P>
                            </SECTION>
                            <SECTION>
                                <SECTNO>§ 172.303</SECTNO>
                                <SUBJECT>QHIN approval and Onboarding.</SUBJECT>
                                <P>(a) An Applicant QHIN has the burden of demonstrating its compliance with all qualifications for Designation in § 172.201 and, if the Applicant QHIN proposes to provide IAS, the qualifications in § 172.202.</P>
                                <P>
                                    (b) If ONC (or an RCE) determines that an Applicant QHIN meets the requirements for Designation set forth in § 172.201, and if the Applicant QHIN proposes to provide IAS, the qualifications set forth in § 172.202, then ONC (or an RCE) will notify the applicant in writing that its application has been approved, and the Applicant QHIN may proceed with Onboarding.
                                    <PRTPAGE P="63809"/>
                                </P>
                                <P>(c) An approved Applicant QHIN must submit a signed version of the Common Agreement within a timeframe set by ONC (or an RCE).</P>
                                <P>(d) An approved Applicant QHIN must complete the Onboarding process, including any tests required to ensure the Applicant QHIN's network can connect to those of other QHINs and other Applicant QHINs, within twelve (12) months of approval of its QHIN application, unless that timeframe is extended in ONC (or an RCE's) sole discretion by up to twelve (12) months.</P>
                            </SECTION>
                            <SECTION>
                                <SECTNO>§ 172.304</SECTNO>
                                <SUBJECT>QHIN designation.</SUBJECT>
                                <P>(a) If all requirements of the Onboarding process specified in § 172.303 have been satisfied:</P>
                                <P>(1) The Common Agreement will be countersigned; and</P>
                                <P>(2) The Applicant QHIN will be provided with a written determination indicating that the applicant has been provisionally Designated as a QHIN, along with a copy of the countersigned Common Agreement.</P>
                                <P>(b) Within thirty (30) calendar days of receiving its provisional Designation, each QHIN must demonstrate in a manner specified by ONC (or an RCE) that it has completed a successful transaction with all other in-production QHINs according to standards and procedures for TEFCA Exchange.</P>
                                <P>(c) If a QHIN is unable to complete the requirement in subsection (b) of this section within the thirty (30)-day period provided, the QHIN must provide ONC (or an RCE) with a written explanation of why the QHIN has been unable to complete a successful transaction with all other in-production QHINs within the allotted time and include a detailed plan and timeline for completion of a successful transaction with all other in-production QHINs. The QHIN's plan will be reviewed and either approved or rejected based on the reasonableness of the explanation and the specific facts and circumstances, within five (5) business days of receipt. If the QHIN fails to provide its plan or the plan is rejected, ONC (or an RCE) will rescind its provisional approval of the application, rescind the provisional QHIN Designation, and deny the application. Within thirty (30) calendar days of end of the term of the plan, each QHIN must demonstrate in a manner specified by ONC (or an RCE) that it has completed a successful transaction with all other in-production QHINs according to standards and procedures for TEFCA Exchange.</P>
                                <P>(d) A QHIN Designation will become final sixty (60) days after a Designated QHIN has submitted its documentation that it has completed a successful transaction with all other in-production QHINs.</P>
                            </SECTION>
                            <SECTION>
                                <SECTNO>§ 172.305</SECTNO>
                                <SUBJECT>Withdrawal of QHIN application.</SUBJECT>
                                <P>(a) An Applicant QHIN may voluntarily withdraw its QHIN application by providing written notice in a manner specified by ONC (or an RCE).</P>
                                <P>(b) An Applicant QHIN may withdraw its QHIN application at any point prior to Designation.</P>
                                <P>(c) Upon written notice to the Applicant QHIN, a QHIN application may be deemed withdrawn as a result of the Applicant QHIN's failure to respond to requests for information from ONC (or an RCE).</P>
                            </SECTION>
                            <SECTION>
                                <SECTNO>§ 172.306</SECTNO>
                                <SUBJECT>Denial of QHIN application.</SUBJECT>
                                <P>If an Applicant QHIN's application is denied, the Applicant QHIN will be provided with written notice that includes the basis for the denial.</P>
                            </SECTION>
                            <SECTION>
                                <SECTNO>§ 172.307</SECTNO>
                                <SUBJECT>Re-application.</SUBJECT>
                                <P>(a) Subject to paragraphs (b), (c), and (d) of this section, applications may be resubmitted by Applicant QHINs by complying with the provisions of § 172.301 in the event that an application is denied or withdrawn.</P>
                                <P>(b) The Applicant QHIN may reapply at any time after it has voluntarily withdrawn its application as specified in § 172.305(a).</P>
                                <P>(c) If ONC (or an RCE) deems a QHIN application to be withdrawn as a result of the Applicant QHIN's failure to respond to requests for information, then the Applicant QHIN may reapply by submitting a new QHIN application no sooner than six (6) months after the date on which its previous application was submitted. The Applicant QHIN must respond to the prior request for information and must include an explanation as to why no response was previously provided within the required timeframe.</P>
                                <P>(d) If ONC (or an RCE) denies a QHIN application, the Applicant QHIN may reapply by submitting a new application consistent with the requirements in § 172.301 no sooner than six (6) months after the date shown on the written notice of denial. The application must specifically address the deficiencies that constituted the basis for denying the Applicant QHIN's previous application.</P>
                            </SECTION>
                        </SUBPART>
                        <SUBPART>
                            <HD SOURCE="HED">Subpart D—Suspension</HD>
                            <SECTION>
                                <SECTNO>§ 172.400</SECTNO>
                                <SUBJECT>Applicability.</SUBJECT>
                                <P>This subpart describes suspension responsibilities, notice requirements for suspension, and the effect of suspension.</P>
                            </SECTION>
                            <SECTION>
                                <SECTNO>§ 172.401</SECTNO>
                                <SUBJECT>QHIN suspensions.</SUBJECT>
                                <P>(a) A QHIN's authority to engage in TEFCA Exchange may be suspended if ONC (or an RCE) determines that the QHIN is responsible for a Threat Condition.</P>
                                <P>(b) If ONC (or an RCE) determines that one of a QHIN's Participants or Subparticipants has done something or failed to do something that resulted in a Threat Condition, ONC (or an RCE) may direct the QHIN to suspend that Participant's or Subparticipant's authority to engage in TEFCA Exchange.</P>
                                <P>(c) ONC (or an RCE) will make a reasonable effort to notify a QHIN in writing in advance of an intent to suspend the QHIN or to provide direction to the QHIN to suspend one of the QHIN's Participants or Subparticipants, and to give the QHIN an opportunity to respond. Such notice will identify the Threat Condition giving rise to such suspension.</P>
                                <P>(d) ONC (or an RCE) shall lift a suspension of either the QHIN or one of the QHIN's Participants or Subparticipants once the Threat Condition is resolved.</P>
                            </SECTION>
                            <SECTION>
                                <SECTNO>§ 172.402</SECTNO>
                                <SUBJECT>Selective suspension of exchange between QHINs.</SUBJECT>
                                <P>(a) A QHIN may, in good faith and to the extent permitted by Applicable Law, suspend TEFCA Exchange with another QHIN because of reasonable concerns related to the privacy and security of information that is exchanged.</P>
                                <P>(b) If a QHIN decides to suspend TEFCA Exchange with another QHIN, it is required to promptly notify, in writing, ONC (or an RCE) and the QHIN with which it is suspending exchange of its decision and the reason(s) for making the decision.</P>
                                <P>(c) If a QHIN suspends TEFCA Exchange with another QHIN under paragraph (a) of this section, it must, within thirty (30) calendar days, initiate the TEFCA Dispute Resolution Process in order to resolve the issues that led to the decision to suspend, or the QHIN may end its suspension and resume TEFCA Exchange with the other QHIN within thirty (30) calendar days of suspending TEFCA Exchange with the QHIN.</P>
                                <P>(d) Provided that a QHIN suspends TEFCA exchange with another QHIN in accordance with this section and in accordance with Applicable Law, such suspension will not be deemed a violation of the Common Agreement.</P>
                            </SECTION>
                        </SUBPART>
                        <SUBPART>
                            <HD SOURCE="HED">Subpart E—Termination</HD>
                            <SECTION>
                                <SECTNO>§ 172.500</SECTNO>
                                <SUBJECT>Applicability.</SUBJECT>
                                <P>
                                    This subpart establishes QHIN termination responsibilities, notice 
                                    <PRTPAGE P="63810"/>
                                    requirements for termination, and the effect of termination.
                                </P>
                            </SECTION>
                            <SECTION>
                                <SECTNO>§ 172.501</SECTNO>
                                <SUBJECT>QHIN self-termination.</SUBJECT>
                                <P>A QHIN may terminate its own Designation at any time without cause by providing ninety (90) calendar days prior written notice.</P>
                            </SECTION>
                            <SECTION>
                                <SECTNO>§ 172.502</SECTNO>
                                <SUBJECT>QHIN termination.</SUBJECT>
                                <P>A QHIN's Designation will be terminated with immediate effect by ONC (or an RCE) giving written notice of termination to the QHIN if the QHIN:</P>
                                <P>(a) Fails to comply with any of the regulations of this part and fails to remedy such material breach within thirty (30) calendar days after receiving written notice of such failure; provided, however, that if a QHIN is diligently working to remedy its material breach at the end of this thirty- (30-) day period, then ONC (or an RCE) must provide the QHIN with up to another thirty (30) calendar days to remedy its material breach; or</P>
                                <P>(b) A QHIN breaches a material provision of the Common Agreement where such breach is not capable of remedy.</P>
                            </SECTION>
                            <SECTION>
                                <SECTNO>§ 172.503</SECTNO>
                                <SUBJECT>Termination by mutual agreement.</SUBJECT>
                                <P>A QHIN's Designation may be terminated at any time and for any reason by mutual, written agreement between the QHIN and ONC (or an RCE).</P>
                            </SECTION>
                        </SUBPART>
                        <SUBPART>
                            <HD SOURCE="HED">Subpart F—Review of RCE or ONC Decisions</HD>
                            <SECTION>
                                <SECTNO>§ 172.600</SECTNO>
                                <SUBJECT>Applicability.</SUBJECT>
                                <P>This subpart establishes processes for review of RCE or ONC actions, including QHIN appeal rights and the process for filing an appeal.</P>
                            </SECTION>
                            <SECTION>
                                <SECTNO>§ 172.601</SECTNO>
                                <SUBJECT>ONC review.</SUBJECT>
                                <P>(a) ONC may, in its sole discretion, review all or any part of any RCE determination, policy, or action.</P>
                                <P>(b) ONC may, in its sole discretion and on notice to affected QHINs or Applicant QHINs, stay any RCE determination, policy, or other action pending ONC review.</P>
                                <P>(c) ONC may, in its sole discretion and on written notice, request that a QHIN, Applicant QHIN, or the RCE provide ONC additional information regarding any RCE determination, policy, or other action.</P>
                                <P>(d) On completion of its review, ONC may affirm, modify, or reverse the determination, policy, or other action under review. ONC will provide notice to affected QHINs or Applicant QHINs that includes the basis for ONC's decision.</P>
                                <P>(e) ONC will provide written notice under this section to affected QHINs or Applicant QHINs in the same manner as the original RCE determination, policy, or other action under review.</P>
                            </SECTION>
                            <SECTION>
                                <SECTNO>§ 172.602</SECTNO>
                                <SUBJECT>Basis for appeal by QHIN or applicant QHIN.</SUBJECT>
                                <P>An Applicant QHIN or QHIN may appeal the following decisions to ONC or a hearing officer, as appropriate:</P>
                                <P>
                                    (a) 
                                    <E T="03">Applicant QHIN.</E>
                                     An Applicant QHIN may appeal a denial of its QHIN application.
                                </P>
                                <P>
                                    (b) 
                                    <E T="03">QHIN.</E>
                                     A QHIN may appeal:
                                </P>
                                <P>(1) A decision to suspend the QHIN or to instruct the QHIN to suspend its Participant or Subparticipant.</P>
                                <P>(2) A decision to terminate the QHIN's Common Agreement.</P>
                            </SECTION>
                            <SECTION>
                                <SECTNO>§ 172.603</SECTNO>
                                <SUBJECT>Method and timing for filing an appeal.</SUBJECT>
                                <P>(a) To initiate an appeal, an authorized representative of the Applicant QHIN or QHIN must submit electronically, in writing to ONC, a notice of appeal that includes the date of the notice of appeal, the date of the decision being appealed, the Applicant QHIN or QHIN that is appealing, and the decision being appealed within fifteen (15) calendar days of the Applicant QHIN's or QHIN's receipt of the notice of denial of a QHIN application, suspension or instruction to suspend its Participant or Subparticipant, or termination. With regard to an appeal of a termination, the 15-calendar day timeframe may be extended by ONC up to another fifteen (15) calendar days if the QHIN has been granted an extension for completing its remedy under § 172.502(a).</P>
                                <P>(b) An authorized representative of an Applicant QHIN or QHIN must submit electronically to ONC, within thirty (30) calendar days of filing the intent to appeal, the following:</P>
                                <P>(1) A statement of the basis for appeal, including a description of the facts supporting the appeal with citations to documentation submitted by the QHIN or Applicant QHIN; and</P>
                                <P>(2) Any documentation the QHIN would like considered during the appeal.</P>
                                <P>(c) The Applicant QHIN or QHIN filing the appeal may not submit on appeal any evidence that it did not submit prior to the appeal except evidence permitted by the hearing officer under § 172.606.</P>
                            </SECTION>
                            <SECTION>
                                <SECTNO>§ 172.604</SECTNO>
                                <SUBJECT>Effect of appeal on suspension and termination.</SUBJECT>
                                <P>An appeal does not stay the suspension or termination, unless otherwise ordered by ONC or the hearing officer assigned under § 172.605(b).</P>
                            </SECTION>
                            <SECTION>
                                <SECTNO>§ 172.605</SECTNO>
                                <SUBJECT>Assignment of a hearing officer.</SUBJECT>
                                <P>(a) On receipt of an appeal under § 172.603, ONC may exercise its authority under § 172.601 to review an RCE determination being appealed. An appealing QHIN or Applicant QHIN that is not satisfied with ONC's subsequent determination may appeal that determination to a hearing officer by filing a new notice of appeal and other appeal documents that comply with § 172.603.</P>
                                <P>(b) If ONC declines review under paragraph (a) of this section, or if ONC made the determination under review, ONC will arrange for assignment of the case to a hearing officer to adjudicate the appeal.</P>
                                <P>(c) The hearing officer must be an officer appointed by the Secretary of Health and Human Services.</P>
                                <P>(d) The hearing officer may not be responsible to, or subject to the supervision or direction of, personnel engaged in the performance of investigative or prosecutorial functions for ONC, nor may any officer, employee, or agent of ONC engaged in investigative or prosecutorial functions in connection with any adjudication, in that adjudication or one that is factually related, participate or advise in the decision of the hearing officer, except as a counsel to ONC or as a witness.</P>
                            </SECTION>
                            <SECTION>
                                <SECTNO>§ 172.606</SECTNO>
                                <SUBJECT>Adjudication.</SUBJECT>
                                <P>
                                    (a) The hearing officer will decide issues of law and fact 
                                    <E T="03">de novo</E>
                                     and will apply a preponderance of the evidence standard when deciding appeals.
                                </P>
                                <P>(b) In making a determination, the hearing officer may consider:</P>
                                <P>(1) The written record, which includes:</P>
                                <P>(i) The RCE's or ONC's determination and supporting information;</P>
                                <P>(ii) Appeal materials submitted by the Applicant QHIN or QHIN under § 172.603.</P>
                                <P>(2) Any information from a hearing conducted in-person, via telephone, or otherwise. The hearing officer has sole discretion to conduct a hearing:</P>
                                <P>(i) To require either party to clarify the written record under paragraph (b)(1) of this section;</P>
                                <P>or</P>
                                <P>(ii) If the hearing officer otherwise determines a hearing is necessary.</P>
                                <P>(c) The hearing officer will neither receive witness testimony nor accept any new information beyond what was provided in accordance with paragraph (b) of this section, except for good cause shown by the party seeking to submit new information.</P>
                            </SECTION>
                            <SECTION>
                                <PRTPAGE P="63811"/>
                                <SECTNO>§ 172.607</SECTNO>
                                <SUBJECT>Determination by the hearing officer.</SUBJECT>
                                <P>(a) The hearing officer will issue a written determination.</P>
                                <P>(b) The hearing officer's determination on appeal is the final decision of HHS unless within 10 business days, the Secretary, in the Secretary's sole discretion, chooses to review the determination. ONC will notify the appealing party if the Secretary chooses to review the determination and will provide notice of the Secretary's final determination.</P>
                            </SECTION>
                        </SUBPART>
                        <SUBPART>
                            <HD SOURCE="HED">Subpart G—QHIN Attestation for the Adoption of the Trusted Exchange Framework and Common Agreement</HD>
                            <SECTION>
                                <SECTNO>§ 172.700</SECTNO>
                                <SUBJECT>Applicability.</SUBJECT>
                                <P>This subpart applies to QHINs.</P>
                            </SECTION>
                            <SECTION>
                                <SECTNO>§ 172.701</SECTNO>
                                <SUBJECT>Attestation submission and acceptance.</SUBJECT>
                                <P>
                                    (a) 
                                    <E T="03">Applicability.</E>
                                     This subpart establishes:
                                </P>
                                <P>(1) The attestation submission requirements for QHINs.</P>
                                <P>(2) The review and acceptance processes that ONC will follow for TEFCA attestations.</P>
                                <P>
                                    (b) 
                                    <E T="03">Submission of QHIN attestation.</E>
                                     (1) In order to be listed in the QHIN directory described in § 172.702, a QHIN must submit all of the following information to ONC:
                                </P>
                                <P>(i) Attestation affirming its:</P>
                                <P>(A) Agreement with and adherence to the Trusted Exchange Framework; and</P>
                                <P>(B) Adoption of the Common Agreement; and</P>
                                <P>(ii) General identifying information, including:</P>
                                <P>(A) Name, address, city, State, zip code, and a hyperlink to its website.</P>
                                <P>(B) Designation of an authorized representative, including the representative's name, title, phone number, and email address.</P>
                                <P>(iii) Documentation confirming its Designation as a QHIN.</P>
                                <P>(2) A QHIN must provide ONC with written notice of any changes to its identifying information provided in accordance with this paragraph (b) within thirty (30) business days of the change(s) to its identifying information.</P>
                                <P>
                                    (c) 
                                    <E T="03">Submission method.</E>
                                     A QHIN must electronically submit its attestation and documentation either via an email address identified by ONC or via a submission on the ONC website, if available.
                                </P>
                                <P>
                                    (d) 
                                    <E T="03">Review and acceptance.</E>
                                     (1) Within thirty (30) business days, ONC will either accept or reject an attestation submission.
                                </P>
                                <P>(2) ONC will accept an attestation if it determines that the QHIN has satisfied the requirements of paragraphs (b) and (c) of this section. ONC will provide written notice to the applicable QHIN's authorized representative that the attestation has been accepted.</P>
                                <P>(3) ONC will reject an attestation if it determines that the requirements of paragraph (b) or (c) of this section, or both, have not been satisfied.</P>
                                <P>(4) ONC will provide written notice to the QHIN's authorized representative of the determination along with the basis for the determination.</P>
                                <P>(5) An ONC determination under this section is final agency action and not subject to further administrative review, except the Secretary may choose to review the determination as provided in § 172.607(b). However, a QHIN may, at any time, resubmit an attestation in accordance with paragraphs (b) and (c) of this section.</P>
                            </SECTION>
                            <SECTION>
                                <SECTNO>§ 172.702</SECTNO>
                                <SUBJECT>QHIN directory.</SUBJECT>
                                <P>
                                    (a) 
                                    <E T="03">Applicability.</E>
                                     This subpart establishes processes for publishing a directory of QHINs on the ONC website.
                                </P>
                                <P>
                                    (b) 
                                    <E T="03">Publication.</E>
                                     (1) Within fifteen (15) calendar days of notifying a QHIN that its QHIN submission has been accepted, ONC will publish, at a minimum, the QHIN's name in the QHIN directory on the ONC website.
                                </P>
                                <P>(2) ONC will identify within the QHIN directory those QHINs that are suspended under the Common Agreement.</P>
                                <P>
                                    (c) 
                                    <E T="03">Removal from the QHIN directory.</E>
                                     (1) A QHIN whose Common Agreement has been terminated no longer qualifies to be included in the QHIN directory as it is no longer considered a QHIN and will be removed from the QHIN directory.
                                </P>
                                <P>(2) Upon termination of a QHIN's Common Agreement, ONC (or an RCE) will send a written a statement of intent to remove the QHIN from the QHIN Directory to the authorized representative of the QHIN.</P>
                                <P>(3) Any written statement given under paragraph (c)(2) of this section shall consist of the following, as appropriate:</P>
                                <P>(i) The name of the terminated QHIN and the name and contact information of the authorized representative of the QHIN.</P>
                                <P>(ii) A short statement setting forth findings of fact with respect to any violation of the Common Agreement or other basis for the QHIN's termination under the Common Agreement and justifying the termination on the basis of those findings of facts.</P>
                                <P>(iii) Other materials as the ONC (or the RCE) may deem relevant.</P>
                                <P>
                                    (d) 
                                    <E T="03">Duration.</E>
                                     A QHIN that is removed from the QHIN directory will remain removed until a new attestation is accepted by ONC in accordance with the processes specified in this subpart.
                                </P>
                                <P>
                                    (e) 
                                    <E T="03">Final agency action.</E>
                                     An ONC determination under this section is final agency action and not subject to further administrative review, except the Secretary may choose to review the determination as provided in § 172.607(b).
                                </P>
                            </SECTION>
                        </SUBPART>
                        <SIG>
                            <NAME>Xavier Becerra,</NAME>
                            <TITLE>Secretary, Department of Health and Human Services.</TITLE>
                        </SIG>
                    </PART>
                </SUPLINF>
                <FRDOC>[FR Doc. 2024-14975 Filed 7-24-24; 8:45 am]</FRDOC>
                <BILCOD>BILLING CODE 4150-45-P</BILCOD>
            </PRORULE>
        </PRORULES>
    </NEWPART>
</FEDREG>
